[PetrHeinz]

Logs sent through this layer reached Better Stack one or two invocations late, and the last invocation's logs before the execution environment shut down never arrived. This forwards each invocation's logs before Lambda freezes the environment, and adds an E2E workflow that follows the AWS Lambda docs article exactly as written to prove it.

Why logs were late:

• The Telemetry API hands the extension an invocation's logs only when its TIMEOUT_MS batching window closes, but Lambda freezes the environment as soon as the runtime and the extension ask for the next event. An invocation's logs reached the extension only when the next invocation thawed it.
• The extension forwarded its queue the moment it received INVOKE, before those logs arrived, so they waited one invocation more. On a quiet function that is minutes.
• On SHUTDOWN the extension forwarded before Lambda handed over the last logs, so those were lost.

The fix:

• The extension also subscribes to platform events, and the HTTP listener tells platform.runtimeDone apart from the function's logs; other platform events are dropped. A batch with a malformed function log is still rejected.
• On INVOKE, the extension waits for that invocation's platform.runtimeDone (events arrive in order, so its logs are queued by then), forwards them in one request, and only then asks for the next event. If the report never comes, it forwards anyway one second before the invocation's deadline, so the extension never makes an invocation time out.
• The request to Better Stack times out after one second. An endpoint that does not answer holds an invocation for at most that long, and the logs stay queued for the next forward.
• An invocation now stays open until Lambda hands over its logs, up to TIMEOUT_MS after the handler finished, plus the request to Better Stack. That time is billed, and a synchronous caller waits for it, so TIMEOUT_MS now defaults to 25 ms, Lambda's minimum, instead of 1000 ms. It is how long Lambda buffers telemetry before the hand-off inside the sandbox, not how often the extension sends to Better Stack, which stays one request per invocation. In the E2E, a handler logging two lines took 344 to 692 ms with the old extension, 1366 to 1428 ms with a 1000 ms window and 435 to 778 ms with 25 ms.

The E2E (.github/workflows/e2e.yml):

• Reads the article's code blocks from the live page and fails when their shape changes. Everything it deploys comes from them: the layer download and publish commands, the environment variables (placeholders filled in as for a signed-in reader), the logging snippets, the pip packages.
• Layer: the daily schedule downloads the release ZIP the article links. Pull requests and pushes to main build the checkout the way releases.yml does, so a PR tests its own changes. The workflow also understands the older build-from-source shape of the article.
• Functions: one per runtime and architecture the article's publish command lists (nodejs22.x and nodejs24.x on x86_64 and arm64), plus python3.11 and python3.14, each with its own source. Each is invoked once as a cold start, read back for 90 s, then invoked four more times 60 s apart. Every logged line must be stored once per invocation, with its level and fields, a dt inside that invocation, in order, and received within 60 s of the invocation returning. The summary says during which invocation Better Stack received each line and lists each invocation's duration.
• AWS: a throwaway account shared with the CloudWatch Lambda E2E of logtail/logtail-aws-lambda. The CI role of this repository may only touch functions, layers and log groups named e2e-lambda-docs-*. Every job deletes what it created and stale leftovers of its own runtime and architecture.

The tests for the fix came first in their own commits (red in CI), then the fixes (green), in #7 and #8, which this PR now contains.

🤖 Generated with Claude Code