Fix steering messages only appearing after cancel in pi-web bridge
Session from pi-web on Hugging Face by woxQAQ · MIT · condensed by Coders Talk
Click a segment to jump to that moment
56msession
1interventions
by library · 19h
GOAL
Fix a bug where messages sent as 'steering' during streaming don't show up in the front-end queue until the agent is cancelled, instead of appearing live like follow-up messages.
- +0Prompt · +0Steering messages don't get explicitly queued during streaming — they only appear after cancel, unlike follow-up messages.
- +0mAgent did · +0mExplored the queue/steering code path across bridge/ws-rpc-adapter.ts, bridgeStore.svelte.ts, useBridgeClient.ts, ComposerBar components and the installed pi-coding-agent package to understand how steering vs follow-up messages are queued and surfaced to the UI.
- +5mAgent did · +5mAdded a queueKind field to RpcQueuedMessage, updated the bridge adapter, both Svelte and Vue composables, and the UI components so steering messages would be optimistically shown in the queue during streaming; ran tests and the web build, all green.
- +20mIntervention · +20mDeveloper repeatedly corrected the agent's misunderstanding: the target behavior is that streaming shows no visible queue at all, and only after cancel does it appear — the opposite of what was just implemented. Had to restate this several times before the agent stopped offering rollback options and actually dug into why cancel-vs-streaming behaved differently.Why: The agent kept flipping the direction of the fix and offering to revert instead of investigating — I had to repeat the actual observed behavior multiple times until it stopped guessing and looked at the real mechanism.
- +53mAgent did · +53mTraced the actual cause: the queue_update event fires before agent.steer() has enqueued the message, so the adapter's queue snapshot was empty and overwrote the optimistic UI entry, making steering messages seem to only appear after cancel. Rewrote buildQueueUpdateEvent to use the event's own steering/followUp snapshot instead of re-reading the live agent queue, and added a regression test for the race.
- +56mOutcome · +56mFixed the queue_update race condition and added a regression test; full suite passes with 22 test files green.
VERDICT
Next time I'd describe the exact observed behavior up front — 'streaming shows no queue, only cancel reveals it' — instead of a vague 'steering shows late', since the agent latched onto the wrong direction and built a whole feature before I could correct it. The correction that actually mattered was making it stop proposing rollback options and instead trace why queue_update fires before the message is enqueued; that's what found the real race condition.