[SLES-2997] fix: stitch split telemetry payloads instead of dropping the batch - #1357
[SLES-2997] fix: stitch split telemetry payloads instead of dropping the batch#1357shreyamalpani wants to merge 6 commits into
Conversation
|
There was a problem hiding this comment.
🟡 Changes recommended
It still logs full telemetry payload bodies on parse failures (risking sensitive-data exposure/log amplification) and has a couple of edge-case behaviors that can reintroduce dropped batches.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Adds robust handling for AWS Telemetry API “split JSON” payloads so oversized telemetry records no longer cause entire batches (including platform.runtimeDone) to be dropped and invocations to hang.
Changes:
- Introduces a fragment buffer + joiner (
stitch.rs) to reassemble split telemetry payloads across consecutive POSTs. - Increases Telemetry API subscription
buffering.maxBytesto 1 MiB and raises the Axum request body limit to accept full-size telemetry posts. - Updates the telemetry listener to attempt reassembly on JSON parse errors and adds tests covering split-payload handling.
File summaries
| File | Description |
|---|---|
| bottlecap/src/extension/telemetry/stitch.rs | New fragment-buffer implementation and unit tests for split-payload reassembly. |
| bottlecap/src/extension/telemetry/mod.rs | Adjusts telemetry subscription buffering settings and subscription logging/behavior. |
| bottlecap/src/extension/telemetry/listener.rs | Uses the stitcher on parse failures, raises request body limit, and adds split-payload handler test. |
Review details
- Files reviewed: 3/3 changed files
- Comments generated: 3
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
|
||
| // Rebuild the cut record's envelope as the continuation will send it: `[` then the | ||
| // record's keys, up to the value that got cut. The cut record is the last one here. | ||
| let value_start = rfind(&body, RECORD_KEY)? + RECORD_KEY.len(); |
There was a problem hiding this comment.
Not sure whether it is over concern, but this still locates the envelope with rfind("\"record\":"). Structured function logs can contain nested record fields. If the split occurs after one, the stitcher builds the wrong repeated envelope, such as "[{"record":{"message":{"record":"XYZ}]"
How about replacing the raw rfind logic with a bounded JSON-aware scanner.
Overview
When a record exceeds the Telemetry API subscription's
maxBytes, AWS cuts it mid-value and sends the remainder in the next POST, which repeats the cut record's envelope ahead of the resumed bytes. Neither half is valid JSON on its own, soserde_jsonfailed and the listener discarded the entire batch — sometimes including theplatform.runtimeDonethat the on-demand loop waits on before calling/next. With that event gone the extension held the invocation open until Lambda killed the sandbox.Changes
extension/telemetry/stitch.rs(new) — buffers the leading fragment and joins the continuation onto it, pairing the two on the repeated envelope (the API gives no sequence number). Joining strips the head's framing and the continuation's repeated envelope.serde_json'sEofcategory); anything elsetakes the existing drop path. One fragment at a time, 2 MiB cap, 1s TTL.
maxBytes256 KiB → 1 MiB (the AWS maximum) — prevention, not the fix. The ~328 KBrecord now arrives in a single POST; stitching covers anything above 1 MiB.
Testing
Manually tested with a repro function emitting a ~330 KB log record, left at the original 256 KiB
maxBytesso every invocation splits: every batch reassembled, 0 parse failures, 0 dropped fragments, invocations 65–102 ms against ~62,000 ms beforehand. This fixes the problem at the root, and does not depend on the buffer increase.Saw debug logs confirming that events were recovered from re-joining the split payload: