* fix: follow session switch when moving between different-agent steps
Moving a task to a workflow step with a different agent profile makes the
backend complete the current session and promote a new primary session for
the new agent. The chat UI was supposed to follow that swap, but the
follow-focus in handleTaskUpdated was suppressed whenever the user had
pinned the session they were on (clicking into a session pins it). The pin
was on the very session being retired, so the user stayed stranded on the
now-completed session — still showing the old agent and plan mode.
The activeSessionId === previousPrimary guard already scopes the follow to
"user is sitting on the session being replaced", so the pin should only
protect a *different* still-live session (active-session drift), never the
one being swapped away. Extract shouldFollowPrimarySwap encoding that rule.
Because it keys off task.updated's primary_session_id it is independent of
WS event ordering and does not depend on the new session row having loaded.
* fix: address review feedback on session-switch follow-focus
Scope the follow-focus fix to genuine session retirement and fix the real
root-cause race, per Greptile/Codex/CodeRabbit review:
- Revert the task.updated pin bypass. Manual "Set as Primary" swaps the
primary without retiring the old session, so bypassing the pin there would
yank a pinned user off a still-live session. Restore pin preservation and
add a guard so a first-primary assignment (null previous primary) never
steals focus.
- Fix the actual bug in the session state-transition handoff: when a retired
session has no non-terminal successor in the per-task list yet (the switch
promotes the new primary via task.updated before the old session's terminal
state_changed lands), fall back to the task's authoritative primary. This
path only runs when the active session truly reaches a terminal state, so it
never fires for manual set-primary.
---------
Co-authored-by: Kandev Agent <agent@kandev.dev>
João Salavisa
350dc0cd21