Bound exec-server pending RPCs#31578
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 48b5c1d242
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
48b5c1d to
5834a74
Compare
b89d367 to
3fe6c5f
Compare
|
@codex review |
|
Codex Review: Didn't find any major issues. Keep them coming! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Why
An untrusted exec-server can stop reading requests, never answer them, or send guessed responses before queued requests are written. Without client-side admission, the orchestrator can retain unbounded RPC call futures and request payloads.
We need a hard bound without adding a blanket timeout, because individual operations already own their timeout and cleanup semantics.
What changed
process/terminateandfs/closeto use one additional cleanup permitTests
rpc_client_call_has_no_implicit_deadlineverifies that ordinary calls remain untimedrpc_client_bounds_in_flight_calls_and_preserves_cleanupcovers the regular-call cap, guessed early responses, cleanup admission, and the cleanup circuit breaker