prisma-risk / tsoracle / 26678500405

95%

push

github

feat(server): configurable GetSeq max count via ServerBuilder::max_seq_count (#584)

* feat(server): configurable GetSeq max count via ServerBuilder::max_seq_count

The per-call ceiling on GetSeq's `count` was a hard-coded core constant
(`MAX_SEQ_COUNT = 65_536`). Unlike the timestamp path's cap — forced by the
18-bit logical field in the packed wire format — nothing in the dense format
requires a particular ceiling (`start` is u64, wire `count` is u32, the durable
counter is u64). It is a soft anti-abuse guardrail (a dense block is
permanently consumed, so the cap bounds how much one call can irrevocably
reserve), which makes it a legitimately deployment-specific policy.

Make it a server-side knob and let the server be the sole authority:

- core: rename `MAX_SEQ_COUNT` → `DEFAULT_MAX_SEQ_COUNT` (it is now a default,
  not a hard limit) and parameterize `SeqAllocator::validate_request(key,
  count, max_count)`. The `count >= 1` floor stays a hard invariant.
- server: `ServingCore` holds `max_seq_count` (mirroring `window_ahead`);
  `ServerBuilder::max_seq_count(u32)` configures it, defaulting to
  `DEFAULT_MAX_SEQ_COUNT`. An over-cap request → INVALID_ARGUMENT.
- client: drop the local `count > MAX_SEQ_COUNT` pre-check — the cap is now
  deployment-specific, so the client forwards `count` and lets the server
  decide. A client built against one cap stays correct against a server
  configured with another. The universal `count == 0` floor is kept.

Default deployments are unchanged (cap still 65_536). Stacked on #579.

Test plan:
- cargo test --workspace --all-features (green)
- cargo clippy --workspace --all-targets --all-features -- -D warnings (clean)
- New tests: core validate_request_uses_caller_provided_max;
  server get_seq_honours_configured_max_seq_count (.max_seq_count(2));
  client get_seq_forwards_large_count_to_server.

Signed-off-by: Sebastian Thiebaud <sebastian@prismarisk.com>

* fix(client): surface over-cap GetSeq as Rpc; reject max... (continued)

152 of 163 new or added lines in 5 files covered. (93.25%)

15357 of 16108 relevant lines covered (95.34%)

351029.02 hits per line