0xMiden / 0xMiden/node

Response size estimates are off

未关闭
#2,310 4 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看
rpc store
主要语言
Rust
星标
104
派生
138
平均合并
1 天 13 小时
30 天内合并 PR
56

描述

`SyncTransactions` can return responses larger than the default tonic decode limit of 4 MB. One observed response from a pioneer was about 6 MB:

```rust
RpcError(RequestError {
endpoint: SyncTransactions,
error_kind: OutOfRange,
source: Status { code: OutOfRange,
message: "Error, decoded message length too large: found 6146702 bytes, the limit is:
4194304 bytes" }
})
```

Account ID was `0x6d37b2d4aedd697140338bb31c67e3`.

For pagination, the response uses the store's `size_in_bytes` estimate, which is obviously different than the actual protobuf-encoded response size. That estimate also undercounts the real payload: `fee` is not counted at all, unauthenticated input notes are estimated at 64 bytes but it ignores the note headers, etc. All this without counting the protobuf framing overhead.

I think @Dominik1999 also hit a similar issue on the `GetNotesById` endpoint, as part of the client's sync state process.

Overall, there are a couple of things to address:

- While the estimate is calculated based on the serialized raw structs, the payload may be filled too close to the 4 MB limit, which will cause the protobuf-encoded message to go over that due to the framing overhead
- Even so, it's clear some limits need to be reviewed because they may not be correctly counted (i.e., 4 MB vs 6 MB is a big enough difference)
- From the client, we do two things: we honor the node-communicated limits for parameters, and we keep the default 4 MB as the maximum-allowed payload size. We should probably bump this limit by 10-15% to allow for overhead if we can't enforce the limit correctly on the node.

贡献指南

打开贡献指南

评估

这个 Issue 还没有评估数据。

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。