Repository navigation
fix(ingest): keep three request costs bounded per request - #2566
Conversation
- A session replay chunk is inflated on the blocking pool, like an OTLP body, so a chunk that inflates to the decoded ceiling does not hold the async workers. - A Vercel audit delivery is refused past 10,000 events. Every event becomes a row of fixed columns, so the byte ceiling alone did not bound what a delivery stores. - A credential longer than any key Maple issues is treated as no credential, before it is hashed, looked up or cached as unknown.
This comment has been minimized.
This comment has been minimized.
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 37 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. |
![maple-review-bot[bot]](https://avatars.githubusercontent.com/in/4108169?s=60&v=4){kind=small}
On the blocking pool many chunks can inflate at once, so each reserves its body and declared size first and is shed with the retryable busy answer when that does not fit. An inline chunk keeps its text reserved until it is stored.
This comment has been minimized.
This comment has been minimized.
…rved The reservation is sized from the gzip trailer, which the sender writes. The inflate now stops at that declared size, so a trailer that understates the stream is refused and cannot get more decoded than was reserved.
|
Addressed the remaining decode-memory point in the latest commit: the inflate now stops at the declared size that was reserved, so a trailer that understates the stream is a 413 and nothing past the reservation is decoded. The bomb test has a case for it. |
Maple review🟢 Confidence 10/10 · safe to merge. The replay decode now reserves from Replay chunk inflate moves to the blocking pool inside the shared decode-memory budget, Vercel audit deliveries are capped at 10,000 events, and ingest credentials over 256 bytes are ignored. The earlier budget-escape finding is fixed; nothing else in the diff is unsafe.
Fixed since the last review
|
What
Part of a pass over every API surface. Three places where one request to the ingest gateway could cost more than its size suggests.
x-maple-ingest-keyvalue longer than 256 bytes is treated as no credential. It is no longer hashed, looked up in Postgres or held in the unknown-key cache.No change to what an accepted request stores.
Verification
cargo test --locked --bin maple-ingest -- extract_ingest_key vercel_audit_drain replay_: all passing, including new tests (a delivery of 10,001 short events is a 413 and nothing reaches the audit trail; an oversized key is ignored in both headers while a 256-byte one is still read). The existing replay tests cover the moved decode (blob store path, inline path, gzip bomb refusal), and the bomb test now also sheds a chunk while the decode memory is full.Not run locally: the load tests. The change moves existing work to another thread and adds two comparisons, so no throughput change is expected.
🤖 Generated with Claude Code
Open in [code]smith · Need help on this PR? Tag
@codesmith-botwith what you need.