Repository navigation
Conversation
…roxy's JoinSet The proxy in front of the Lambda Runtime API spawns two tasks per invocation into a JoinSet that is joined only at shutdown, so the set grows by two finished tasks per invocation. Remove finished tasks before each spawn, as the lifecycle listener does. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
The helper-only test would pass even without production task reaping, so a process-level regression is needed to check bounded memory growth after warmup on Linux and clean shutdown.
1 open issue
What changed in this PR
This PR prevents completed tasks from accumulating in the Lambda Runtime API proxy, applying the lifecycle listener’s cleanup pattern from #1508.
Changes:
- Drain completed tasks before spawning invocation-event and response tasks.
- Preserve shutdown handling for tasks still running.
- Add a unit test verifying that the cleanup helper removes completed tasks.
| File | Description |
|---|---|
bottlecap/src/proxy/interceptor.rs |
Adds completed-task cleanup at both spawn sites and a helper unit test. |
Review effort: Balanced
| // Let the spawned tasks finish. | ||
| tokio::task::yield_now().await; | ||
|
|
||
| reap_finished(&mut join_set); |
Contributor
|
This comment will be updated automatically if new data arrives. 🔗 Commit SHA: d9e3686 | Docs | View more details | Give us feedback! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Problem
The extension can run a proxy in front of the Lambda Runtime API. It starts the proxy when the function uses Lambda Web Adapter or the Datadog wrapper, for example with App and API Protection. For each invocation, the proxy starts two tasks in a Tokio
JoinSet: one for the event and one for the response. AJoinSetkeeps each finished task until something joins it, and the proxy joins only at shutdown. So the set grows by two tasks per invocation for the life of the execution environment.This is the same pattern that #1508 fixes in the listener for the tracer's start and end calls. That leak made the extension's memory grow about 14 KB per invocation in #1496. I have not measured the memory growth from the proxy.
This PR
Before each new task, the proxy removes the tasks that have finished, with
JoinSet::try_join_next(). This is the same change as #1508. Each module keeps its own copy of the helper, as each already keeps its own shutdown function for its set. The proxy still joins the tasks that are running at shutdown.This PR is based on #1508. Merge #1508 first.
Testing
Steps
cargo test --lib proxy::interceptor.Result
The new test starts 10 tasks that finish at once, calls the helper, and counts the tasks left in the set.
The test covers the helper only. I did not run the proxy on Lambda. The calls to the helper are the two lines added before each
spawn.🤖 Generated with Claude Code