[SLES-2997] fix: stitch split telemetry payloads instead of dropping the batch

[shreyamalpani]

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, so serde_json failed and the listener discarded the entire batch — sometimes including the platform.runtimeDone that 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.
  • Only payloads cut mid-value are held (serde_json's Eof category); anything else
    takes the existing drop path. One fragment at a time, 4 MiB cap (a full POST can be 2 * maxBytes + metadataBytes), 1s TTL.
• maxBytes 256 KiB → 1 MiB (the AWS maximum) — prevention, not the fix. The ~328 KB
  record now arrives in a single POST; stitching covers anything above 1 MiB.
• Listener body limit 2 MiB → 4 MiB — axum's default would reject a full-size POST before the handler sees it, since the API can send up to 2 * maxBytes + metadataBytes.

Testing

Manually tested with a repro function emitting a ~330 KB log record, left at the original 256 KiB maxBytes so 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:

{
    "status": "DEBUG",
    "message": "DD_EXTENSION | DEBUG | TELEMETRY API | Reassembled a split payload, recovered 4 events"
}

[datadog-prod-us1-5]

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: bc6ca89 | Docs | View more details | Give us feedback!}

[Copilot]

🟡 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.maxBytes to 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.

[litianningdatadog]

Commented.

[litianningdatadog]

Discovered by AI: looks like next_event invocation incorrectly twisted the position of runtime_id and extension_id in this line. Since this PR starts return Err on the rejected subscriptions, that error bubbles out of extension_loop_active, and the caller explicitly falls back to extension_loop_idle. I think we should fix that in this PR.