Remove queue code made dead by the Runtime Host per-entry queue operations
- Dominant language
- TypeScript
- Stars
- 5.4k
- Forks
- 502
- Avg merge
- 1d 2h
- Merged PRs (30d)
- 715
Description
Follow-up from #3544 (per-entry composer queue: `queue.entry.retract` / `queue.entry.promote` / `queue.entries.reorder`, protocol epoch 40). A simplification audit of that change surfaced three pre-existing code paths whose last real consumer is gone now that the Runtime Host is the complete queue authority. Each is a separate, independently revertable deletion; they should land as their own PR(s), not inside #3544.
## 1. CLI fallback retry machinery (~150 lines)
`packages/cli/src/pi-tui-runner.ts`: `state.pendingFallback`, `deferFallback`, `scheduleFallbackRetry` / `retryPendingFallback` / `stopFallbackRetry`, `takePendingFallbackEntries(Settled)`, `FALLBACK_RETRY_MS`, the fallback branches in the submit path, the turn-boundary flush, and the pendingFallback merge in `packages/cli/src/pi-transcript.ts` (pending bar).
Evidence: the only production driver is `RuntimeHostMakaSessionDriverImpl` (sole factory `createRuntimeHostMakaSessionDriver`, sole entry `runtime-host-tui-command.ts`). Its `#enqueue` returns `fallback` only when there is no `sessionId`, while `steerRunningTurn` / `handleAltEnter` are only reachable with a turn running, i.e. a session must exist. Only test doubles ever return `fallback`. The `MakaSessionDriver.steer/queueMessage` contract permitting `fallback` is generality kept for a hypothetical embedded driver. Note: `trackEnqueue` / `settlePendingEnqueues` are NOT part of this — the interrupt path still needs their in-flight submit ordering.
## 2. CLI `takePendingFollowup` null stub and its consumer block (~30 lines)
`packages/cli/src/session-driver.ts` interface method, the always-null stub in `runtime-host-session-driver.ts` (its own comment says the Host starts queued follow-ups atomically, so returning text would make the TUI double-submit), and the consumption block in `pi-tui-runner.ts` that re-queues or folds the text into `nextPrompt`. Production always sees `null`; the only non-null implementations are test doubles, so tests exercise a path production can never reach.
## 3. runtime-kernel embedded message queue API (~60 lines plus tests) — needs one decision first
`packages/runtime/src/runtime-kernel.ts`: `steer` / `queueMessage` / `drainFollowup` / `retractQueue` (the coarse, `\n\n`-joining text queue), and the four pure pass-through methods in `session-manager.ts`. Production call sites: zero (desktop steers via Host `turn.message.submit`; the CLI drives the Host). The only consumers are `session-manager.test.ts`. `assertEmbeddedMessageQueue` already throws in hosted mode, and the single production composition always passes `messageAuthority`.
Decisive check before deleting: confirm that an embedded (Host-less) SessionManager composition is not a publicly documented/supported product shape (check ARCHITECTURE.md and docs/). If it is not, the block goes together with its tests. The `SessionSteeringState` lease/pull delivery used by hosted mode (`bindMessage`) is out of scope and stays.
## Verified as still needed (do not remove)
- Host op `queue.retract` (retract-all): consumed by the CLI TUI interrupt and alt+up paths via `driver.retractQueued()`; the CLI has no per-entry UI.
- `sessions:steer` / `sessions:enqueue` desktop IPC: live consumers (workbar side-chat, renderer enqueue).
- The `session_busy` fallback in `sessions:send`: the race it covers still exists for skill/orchestration sends and side-chat.
- `QueueUpdateEvent.steering` / `followup` string arrays: the CLI pending bar reads them.
Contributor guide
Assessment
This issue has not been assessed yet.