The regression test for the pane-creation race (PR #4052 / issue #3505)
previously didn't enforce the readiness-then-spawn ordering: mocks
resolved synchronously and the assertion only checked the final
behavior, not the sequencing. A future code change reintroducing the
race could slip past this test silently.
Rewrites the test to explicitly assert call ordering:
waitForSessionReady must complete before executeActions is invoked.
A failure case is added where waitForSessionReady remains pending
when executeActions would otherwise fire; the test asserts the spawn
is correctly deferred.
Addresses cubic-dev-ai's review on PR #4052 (severity 5/10,
test quality).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Fixes BackgroundManager to launch promptAsync before invoking the blocking tmux callback.
- Adds regression test to ensure promptAsync is called before tmux callback.
`opencode attach` was invoked inside a freshly-split tmux pane before the
child session appeared in the opencode server's status map. The process
exited immediately (session not found), tmux auto-closed the pane, and the
subagent ran invisibly in the background — the race documented in #3505.
Fix: call `waitForSessionReady` *before* `executeActions` in
`session-created-handler.ts`, mirroring the guard already present in
`TmuxSessionManager.ensureSessionReadyBeforeSpawn()`. If the session does
not become attachable within the timeout the handler returns early without
spawning a pane at all, eliminating the transient-pane and silent-close
failure modes. The now-unreachable post-spawn readiness-check / pane-close
cleanup branch is removed.
Adds a regression test suite (session-created-handler.test.ts) covering:
- not-ready session → no pane spawned, no polling started
- duplicate session.created → idempotent
- non session.created event type → no action
- already-tracked session → idempotent
Closes#3505
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Keep prompt reservations briefly after successful dispatch so rapid idle/message/error transitions cannot inject the same follow-up twice.
Route all production session prompt calls through the shared gate, restore skipped background resume state, release holds after abort/recovery paths, and preserve Ralph/ULW loop state when a dispatch is deferred.
Add regression coverage for session routing, static prompt route auditing, team-mode live messaging, model suggestion retries, call-omo-agent reuse, background parent wakes, runtime fallback, compaction recovery, Atlas, and Ralph/ULW loops.
scheduleForcedExit was called without exitAfterCleanup=true for SIGTERM/SIGINT.
After cleanup completed, timeout cleared but process.exit() never called.
Process stayed alive waiting for event loop to drain.
Benchmark (systemctl stop):
- Before: 10s+ timeout (systemd had to SIGKILL)
- After: ~30ms instant shutdown
Test results (3 runs):
- Test 1: 30ms
- Test 2: 28ms
- Test 3: 27ms
When many background tasks complete in rapid succession while the parent
session is idle, each completion fired its own promptAsync call, stacking
N consecutive `<system-reminder>` user messages with no assistant turn
between. Hyperplan + many parallel explore subagents made this very
visible to the user.
Route the idle-path through the existing pendingParentWakes queue with a
100ms debounce window. Notifications arriving during the debounce join
the same batch, the 150ms settle window also coalesces newcomers, and a
single batched prompt fires to the parent. Busy-path semantics are
unchanged (still 1s retry).
Prior attempts (1c05c60dc, ea55c385b, a337635e3) all coalesced only the
busy-defer path, leaving the idle-immediate-send path uncoalesced.
Reframe the skill's Lifecycle section so the lead treats teams as
ephemeral, one-per-phase units. The moment a phase ends or the shape
no longer fits, call team_delete and spawn a fresh team. Restructure
through delete-then-create, never in place.
Also fixes a misframing in old step 5: team_shutdown_request is a
per-session self-shutdown signal, not a 'wind down the team' command.
team_delete is what tears the whole team down.
Sync the PR branch with the newest dev branch and resolve the new import-level conflicts in background-agent manager and runtime-fallback tests. Preserve both the delegated bootstrap coverage from this branch and the newer upstream test utilities and runtime wiring changes, then re-verify the affected delegated fallback suites and typecheck.
Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent)
Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
The circuit breaker in manager.ts uses recordToolCall to detect when a subagent gets stuck repeating identical tool_use blocks. It passed partInfo.state?.input as the tool-input signature. When a model (Kimi K2.6 in the reporter's case) emits duplicate tool_use parts faster than the tool actually starts running, state.input is still null, so loop-detector falls back to the bare 'tool::__unknown-input__' signature. As soon as one part has state.input populated (next event), the signature flips to 'tool::{actual-args}' and the consecutive counter resets to 1, repeatedly. The breaker never reaches its 20-call threshold.
Add a top-level input?: Record<string, unknown> field to the local MessagePartInfo interface and prefer state.input when present, falling back to the part's own input when state is still pre-running. The OpenCode part payload carries the tool input as soon as the tool_use block is generated, so this fallback restores signature stability across the model's repeated emissions.
Verification: added 2 regression tests in manager-circuit-breaker.test.ts. Test 1 (reproduce) emits 20 part.updated events with only top-level input and asserts the task is cancelled by the breaker — fails before the fix, passes after. Test 2 confirms that when state.input IS present, it still wins over the top-level input (precedence preserved). All 10 manager-circuit-breaker tests pass, all 20 loop-detector tests pass, typecheck clean.
Cubic AI reviewer flagged the use of the untrusted Host header as the
URL base in startCallbackServer. The server only binds to 127.0.0.1,
so hardcoding "http://127.0.0.1" as the URL base is robust against
malformed or manipulated Host values and matches upstream behavior
prior to the node:http refactor.
Disaster-Terminator