Repository navigation
Disable unbounded connection retries for protected Codex launches - #3310
Conversation
Stamp a private Compute admission fact for new protected Codex inference revisions and disable unbounded connection retries in the startup probe and app-server launch. Preserve legacy launch bytes and reject incompatible admission markers. Extend the local enrollment integration to cover admission, native arguments, both launch forms, and refusal controls.
freeqaz-openai
added
the
agent-created
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
clawsweeper
Bot
added
clawsweeper:intake:bug
Workspace rendering does not need to inspect admission. Pass the validated workspace command to new and replacement deployments; ordinary callers retain the existing default.
clawsweeper
Bot
added
P2
|
Codex review: needs maintainer review before merge. What this changesThis PR disables native connection waiting in the probe and app-server for newly admitted protected dedicated Codex revisions. Example: A protected Codex launch encounters an unavailable Responses endpoint that later starts listening.
Review scores
ProductKind: Bug fix · Worth it: Yes · Fix scope: Complete Merge readiness✅ Ready for maintainer review The prior documentation finding is resolved, and this review found no remaining actionable defect. Keep this maintainer-authored PR open for normal landing review; CI is still running. Priority: P2 Before mergeNone. FindingsNone. Agent review detailsHow this fits togetherKubernetes Compute converts immutable Agent revision admission into direct or workspace-node Harness commands, which launch the Codex authentication probe and app-server. flowchart TB
A[Agent deployment] --> B[Compute admission]
B --> C[Stored Agent revision]
C --> D[Compute launch selection]
D --> E[Codex authentication probe]
D --> F[Codex app server]
E --> G[Responses endpoint]
F --> G
Technical reviewBest possible solution: Land the focused launch change with its existing revision boundary and documented controller-and-worker rollout order. Do we have a high-confidence way to reproduce the issue? Current main omits the native feature disable despite zero provider retry budgets, and the author reports a controlled native base/head comparison; this review executed no target runtime. Is this the best way to solve the issue? The change addresses the native connection-wait owner directly, reuses existing launch templates and admission storage, and preserves immutable commands for existing revisions. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against 870cf5d8e1a6. Provenance checked
TestingProof path: shipped entry point. SecurityNone. EvidenceWhat I checked:
Likely related people:
LabelsLabel changes:
Label justifications:
Rating scale6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior. WorkflowClawSweeper edits this one comment on every review. Comment HistoryReview history (1 earlier review cycle)
Reviewed October 23, 2026, 9:57 AM ET / 13:57 UTC (Revision 2). |
|
@clawsweeper re-review Fixed the requested documentation limit and the other red CI lane in Here is the requested native comparison through the generated protected startup, using the shipped Codex 0.163.0-alpha.2, signed fixture enrollment and a loopback TLS Responses endpoint. A small event tap forwarded the probe's actual arguments and output and told the fixture when to open the listener. Each arm ran one probe attempt; the observable was an HTTP POST at the receiver, not an inference from the startup status.
On the refused arm we kept the listener open through the terminal probe result and another 1.4 seconds, then retired the fixture. This is a finite observation, not a claim about every network failure, redirects, or exactly-once delivery. A separate run exercised the generated direct and workspace-node commands and two turns in the same conversation. No real provider credential or service was involved. |
|
🦞👀 Re-review progress:
|
clawsweeper
Bot
added
clawsweeper:intake:bug
) Adds a conformance check that the Kubernetes driver renders the protected Codex launch command from #3310 for admitted protected revisions, with and without a workspace node, and the legacy command for unmarked revisions. Reverting the entrypoint selection or the prepare-time workspace node now fails it. This also guards the line that open #2982 rewrites.
With request and stream retry limits set to zero, Codex can still wait after an initial connection failure and send a protected model request when the endpoint becomes available.
For newly admitted Kubernetes revisions using dedicated Codex with protected inference, disable
unbounded_connection_retriesin the authentication probe and app-server. This covers inference routes and separately admitted model credentials alongside Git. Existing revisions retain their exact launch commands; older workers reject the new admission marker. Roll out the updated controller and workers before creating a new Agent revision to pick up this behavior.Validation used the shipped Codex binary with a controlled local endpoint. The default configuration waited and sent after the endpoint became available; the new setting terminated without a request to the later listener. An already available endpoint succeeded. A driver-produced launch also completed two conversation turns with continuity. Relevant integration tests, type checking, lint and formatting passed. These checks do not establish behavior for other network failures or a real deployment.