Problem
A controller and Lab runner aligned on the same current release could not admit a four-cell Cook fanout immediately after a successful refresh-homeboy --reconnect.
The environment was explicitly converged first:
homeboy upgrade --force --skip-runners
homeboy runner refresh-homeboy homeboy-lab --ref v0.304.0 --reconnect
Both controller and active daemon reported homeboy 0.304.0+3e0ece8b6f14. The refresh returned daemon_refreshed: true, reconnect_required: false, and success.
A collision-safe custom fanout then dispatched four unique children. During admission Homeboy reported:
Lab offload: runner homeboy-lab is connected via direct SSH mode.
Lab offload: direct SSH runner homeboy-lab is not connected; attempting connection.
The outcomes were:
cook-issue-9621-v2: selected runner homeboy-lab cannot accept jobs
cook-issue-9623-v2: selected runner homeboy-lab cannot accept jobs
cook-issue-9624-v2: runner refused Lab admission reservation: daemon lease is not fresh
cook-issue-9626-v2: selected runner homeboy-lab cannot accept jobs
One cell reached remote preacceptance and its run-scoped workspace was materialized; all four terminalized as pre_execution_failure before provider execution.
This reproduces the user-facing contract from closed #9466 on v0.304.0 and overlaps the concurrency failure class from closed #8626, but with a freshly refreshed identical-build daemon. It is not #9626, which concerns dispatch through a known stale command binary.
Impact
A one-command fanout turns into daemon/session repair, unique rerun-ID management, and abandoned pre-execution recipes. The operator cannot trust successful refresh/reconnect as readiness evidence.
Expected contract
refresh-homeboy --reconnect returns success only when the selected daemon lease and admission endpoint are ready for the next bounded parallel fanout. Concurrent child admission shares one authoritative session and cannot invalidate it underneath sibling cells.
Acceptance criteria
- Reproduce refresh/reconnect followed immediately by at least four parallel Cook child admissions.
- Keep one authoritative direct-SSH session and daemon lease stable across all sibling reservations.
- Serialize or queue admission/reconnect ownership rather than allowing child commands to invalidate the shared session.
- Make refresh perform a bounded admission reservation readiness probe before returning success.
- Automatically recover transient
daemon lease is not fresh and connection flips within the original child lifecycle.
- Do not consume provider budget or permanently strand a Cook recipe on preacceptance transport failure.
- Return one batch-level recovery action when automatic recovery is exhausted.
- Cover same-build reconnect and concurrent fanout, not only stale-binary replacement.
Evidence
AI assistance
- AI assistance: Yes
- Tool: OpenCode
- Model: OpenAI GPT-5.6 Sol
- Used for: Converged controller/runner versions, executed the parallel fanout, captured admission failures, deduplicated prior lease issues, and drafted this issue. Chris reviewed and owns the report.
Problem
A controller and Lab runner aligned on the same current release could not admit a four-cell Cook fanout immediately after a successful
refresh-homeboy --reconnect.The environment was explicitly converged first:
Both controller and active daemon reported
homeboy 0.304.0+3e0ece8b6f14. The refresh returneddaemon_refreshed: true,reconnect_required: false, and success.A collision-safe custom fanout then dispatched four unique children. During admission Homeboy reported:
The outcomes were:
One cell reached remote preacceptance and its run-scoped workspace was materialized; all four terminalized as
pre_execution_failurebefore provider execution.This reproduces the user-facing contract from closed #9466 on v0.304.0 and overlaps the concurrency failure class from closed #8626, but with a freshly refreshed identical-build daemon. It is not #9626, which concerns dispatch through a known stale command binary.
Impact
A one-command fanout turns into daemon/session repair, unique rerun-ID management, and abandoned pre-execution recipes. The operator cannot trust successful refresh/reconnect as readiness evidence.
Expected contract
refresh-homeboy --reconnectreturns success only when the selected daemon lease and admission endpoint are ready for the next bounded parallel fanout. Concurrent child admission shares one authoritative session and cannot invalidate it underneath sibling cells.Acceptance criteria
daemon lease is not freshand connection flips within the original child lifecycle.Evidence
homeboy-orchestration-papercuts-20260722-v3cook-issue-9621-v2,cook-issue-9623-v2,cook-issue-9624-v2,cook-issue-9626-v2AI assistance