fix(fleet): timeout crabbox inspect and warmup - #77
Conversation
Route Crabbox inspect and warmup through run_with_timeout so a hung coordinator cannot pin the native fleet controller. Stop already used that helper; inspect and warmup still called unbounded subprocess.run. Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca>
|
🦞👀 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. |
|
Codex review: blocked before merge. Reviewed September 4, 2026, 12:53 PM ET / 16:53 UTC. ClawSweeper reviewWhat this changesThe PR adds fixed subprocess deadlines to Crabbox lease inspection and warmup, with regression coverage for timeout handling. Regression provenancePossible regression — suspected (reviewed change). No predecessor PR is attributed. Merge readiness⛔ Blocked before merge - 3 items remain Keep open: the timeout fix has credible real-process proof, but it breaks the existing injected-executor boundary. A caller that supplies an executor implementing the prior run-only contract now fails in lease inspection or warmup with AttributeError; this is the unresolved prior P2 finding on the unchanged PR head. Priority: P2 Review scores
Verification
How this fits togetherThe native fleet controller provisions and inspects Crabbox AWS leases before dispatching benchmark runs. It invokes the Crabbox CLI through an injectable command executor and turns lease results into scheduling state. flowchart LR
A[Native evaluation command] --> B[Fleet controller]
B --> C[Lease inspection]
B --> D[Lease warmup]
C --> E[Command executor]
D --> E
E --> F[Crabbox coordinator]
F --> G[Ready lease]
G --> H[Remote benchmark run]
Before merge
Findings
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Copy recommended automerge instructionTechnical reviewBest possible solution: Keep the production subprocess deadlines, but retain the run-only fallback for injected executors and add focused coverage for both lease operations. Do we have a high-confidence way to reproduce the issue? Yes. The supplied real-child trace shows the bounded production paths returning promptly, and the fetched main source confirms the corresponding unbounded calls that make the hang reproducible. Is this the best way to solve the issue? No. Fixed deadlines are the right production remedy, but unconditionally requiring a new executor method is not the narrowest compatible implementation; preserve the established injected-executor fallback. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: not found in the target repository. Codex review notes: model internal, reasoning high; reviewed against c1a79f731541. LabelsLabel justifications:
EvidenceAcceptance criteria:
What I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (9 earlier review cycles; latest 8 shown)
|
What Problem This Solves
The native fleet controller talks to Crabbox over
inspectandwarmupto lease AWS machines. Those two CLI calls used
SubprocessExecutor.run(),which wraps
subprocess.runwith no timeout. Onlycrabbox stopalreadyused
run_with_timeout.If the coordinator never returns, the controller stays blocked in that
child. A native eval wave cannot recover, re-lease, or export while inspect
or warmup is stuck. The public path is
python -m scripts.native_eval.fleet.Evidence
Live
python3on this branch pointedcrabbox_binat a real 30-secondsleepchild.FleetController._inspect_leaseand_warmup_leasebothreturned a
FleetErrorin 0.40s instead of waiting for the child to exit.SubprocessExecutor.run()without a timeout was still running after 1sand finished only when the 30s sleep ended.
Real behavior proof
Behavior or issue addressed: Hung Crabbox
inspectandwarmupcould pin the native fleet controller because those lease CLI calls used unboundedsubprocess.run. They now go throughrun_with_timeoutand return exit 124 withtimed out after ...s.Real environment tested: macOS Darwin 25.6.0 arm64, Python 3.14.7, checkout
/tmp/oc-pr-shellbench-F004onfix/f004-fleet-subprocess-timeout.Exact steps or command run after this patch:
Evidence after fix: terminal output from the live command:
Observed result after fix: Inspect and warmup returned in 0.40s against a 30s child. Production bounds stay 45s for inspect and 120s for warmup. The same child under unbounded
run()stayed alive past 1s and exited 0 after 30.13s.What was not tested: A live Crabbox coordinator hang against real AWS leases.
What does this PR do?
Route Crabbox
inspectandwarmupthroughrun_with_timeout, the samehelper already used for
crabbox stop.Why?
Unbounded
subprocess.runlanded with the native fleet runner in#42
(
69f75c6629c4,2026-07-29).
run_with_timeoutwas added later the same day for stoponly (
b9acd9f7). Related timeout class:#66. No open pull request
already changes inspect or warmup.
Changes
CommandExecutornow includesrun_with_timeoutTests
python -m pytest -q tests/test_native_eval_fleet.pypasses locallypython -m ruff check scripts/native_eval/fleet.py tests/test_native_eval_fleet.pypasses locally