fix: don't let a slow log endpoint hold every Lambda invocation

[alongubkin]

Problem

#970 made the Lambda wait_until extension flush application logs after every invocation, waiting up to the invocation deadline minus 250 ms. Lambda doesn't give an environment its next invocation until the extension returns, so each invocation now holds its environment for as long as the OTLP export takes. With the default 180 s timeout the wait is bounded only by the SDK's 5 s force_flush timeout.

Load test, 20 rps for 3 minutes against a function URL, simple worker that logs one line per request (arm64, 512 MB, 180 s timeout; test account with a 10-concurrent-execution limit):

log endpoint	runtime	ok / sent	Lambda Duration p50	billed avg	logs delivered
healthy	before #970	3600 / 3600	3.3 ms	5.3 ms	3571 / 3600
healthy	#970	3600 / 3600	4.5 ms	6.8 ms	3600 / 3600
healthy	this PR	3600 / 3600	4.0 ms	5.5 ms	3600 / 3600
+1.5 s latency	before #970	3600 / 3600	2.7 ms	4.4 ms	3506 / 3600
+1.5 s latency	#970	1152 / 3600 (2448 × 429)	1506 ms	1518 ms	1152 / 1152
+1.5 s latency	this PR	3500 / 3600 (100 × 429)	3.1 ms (p95 505)	135 ms	3492 / 3500
unreachable (SYN dropped)	before #970	3597 / 3600	2.9 ms	6.9 ms	0
unreachable	#970	360 / 3600 (3240 × 429)	5003 ms	5028 ms	0
unreachable	this PR	3578 / 3600 (22 × 429)	2.6 ms (p95 504)	50 ms	0

Client latency of successful requests is unchanged in every row (p50 55-57 ms). The cost shows up as concurrency: with #970 each environment serves at most one request per export time, so an unreachable endpoint needs ~1000x the environments, and a slow one ~350x the billed time. In an account with a normal concurrency limit that is a large bill; at the limit it throttles callers.

Fix

• An invocation waits at most 500 ms for its export (still never past the deadline minus 250 ms). A healthy endpoint answers well inside that.
• If an earlier export hasn't finished, the invocation doesn't start or wait for another. Its records stay in the batch and go out with the next export. An unreachable endpoint then holds one invocation per stuck export instead of every invocation.
• Failures are still logged, never returned to the caller.

Alternatives: a shorter fixed cap alone still holds every invocation during an outage (500 ms each); skipping alone still holds every other invocation for the SDK's 5 s flush timeout; a SimpleLogProcessor exports inside the request path.

Proof

• an_unanswered_log_endpoint_does_not_hold_every_invocation: an exporter that blocks until released, driven through the real extension INVOKE handler. First invocation is held ≥500 ms and <1 s, the second <100 ms, and after release a third invocation exports all three lines in order. With fix: export Lambda application logs before the environment freezes #970's behavior restored: first invocation held for 5.001s, fails.
• the_log_export_wait_is_bounded_and_stops_short_of_the_deadline fails on fix: export Lambda application logs before the environment freezes #970's wait (9.75s vs 500ms).
• cargo test -p alien-worker-runtime: all pass.
• Live numbers above: the runtime binary built from each commit, layered over the published v3.3.31 TypeScript worker image, one Lambda per runtime, OTLP sink on EC2 with a fast port, a +1.5 s port and a dropped port.
• Streaming (ALIEN_LAMBDA_MODE=streaming, RESPONSE_STREAM URL, 1 s body, log line written just before the body closes): TTFB ~100 ms, Duration ~1008 ms, every line delivered by the end of the response with fix: export Lambda application logs before the environment freezes #970 and with this PR, so the invocation ends when the body ends. With an unreachable endpoint, fix: export Lambda application logs before the environment freezes #970: Duration 6.0 s and 28/120 throttled at 2 rps; this PR: 0 throttled.

Rollout

Ships in the worker base image with the next release. Without this, #970 should not be released.

ALIEN-1366

🤖 Generated with Claude Code

[enclave-ai]

Enclave skipped this draft pull request. It will run automatically when you mark the PR as Ready for review.

[alongubkin]

@greptileai review

[greptile-apps]

Confidence Score: 5/5

[High impact] The PR appears safe to merge; the latest change fixes the blocked-exporter cleanup issue.

Summary

The PR caps each invocation’s log-export wait at 500 ms and skips another export while an earlier one is still running.

• Lambda log exports no longer hold every invocation for a slow endpoint.

_{Reviews (3) · Last reviewed commit: "test: release the unanswered endpoint ev..." · Reviewed by Greptile}

[alongubkin]

@greptileai review