iotaledger / iota

69%

Build Type

push

github

Committed by web-flow

Commit Message

fix(iota-grpc-server): feed embedded batch errors into the traffic-control error policy (#12131)

# Description of change

The e2e migration of the traffic-control tests off the node JSON-RPC
(#12130) surfaced gaps in the fullnode gRPC traffic control around
**batch APIs**:

1. **Embedded per-item errors never fed the error policy.** Batch APIs
report per-item failures as `google.rpc.Status` values embedded inside
an otherwise *successful* gRPC response. The `TrafficControlLayer`
derives its tally from the transport-level status only, so a client
spamming e.g. invalid transactions produced `Code::Ok` tallies and could
never be error-blocked.
2. **A batch counted as a single request under the spam policy**,
regardless of how many items it carried — so a client could dilute its
request rate simply by batching.

(The first gap was originally misdiagnosed as a headers-vs-trailers
issue; the `handler_errors_feed_the_error_policy` test shows unary
handler errors *are* visible to the layer — tonic returns them as a
trailers-only response, so `grpc-status` is in the HTTP headers. The
real blind spot is the batch response body.)

## Fix

- `TrafficControlLayer` injects a `TallyHandle` (client IP + traffic
controller) into the request extensions.
- Batch handlers report **each item** through the handle: every item
counts as one request for the spam policy and, on a client error, feeds
the error policy. The layer skips its default per-request tally when a
handler has accounted for the items (no double counting).
- Endpoints covered:
- `ExecuteTransactions`, `SimulateTransactions` — unary; tallied per
response item.
- `GetObjects`, `GetTransactions` — server-streaming; tallied per item
as the response stream is consumed. Per-item read failures ride inside
`Ok` responses and are tallied as `Code::Ok` (a client cannot know an
object or transaction was pruned), so they feed the spam policy only. A
stream-level error (e.g. a single item exceeding the request's messag... (continued)

Coverage Stats

79 of 89 new or added lines in 4 files covered. (88.76%)

3131 existing lines in 88 files now uncovered.

168080 of 244384 relevant lines covered (68.78%)

459535.24 hits per line