Skip to content

Keep Direct Chat controls scoped to the selected session - #929

Draft
Y1fe1Zh0u wants to merge 1 commit into
mainfrom
agent/fix-direct-chat-session-isolation
Draft

Keep Direct Chat controls scoped to the selected session#929
Y1fe1Zh0u wants to merge 1 commit into
mainfrom
agent/fix-direct-chat-session-isolation

Conversation

@Y1fe1Zh0u

Copy link
Copy Markdown
Collaborator

What changed

  • Project Direct Chat runtime controls through the currently selected Session.
  • Prevent delayed sends from a background Session from mutating the visible composer or message list.
  • Add regression coverage for Session-scoped controls and delayed WebSocket sends.

Why

When one Session was still running, switching to another Session could retain the first Session's blocked-input state and stop button. The component had both per-Session runtime caches and a component-wide activeRun, so stale or delayed state could leak across the selection boundary.

After this change, background Sessions continue running, but only the selected Agent/Session pair may update the visible chat controls.

Validation

  • cd frontend && npm test — 90 passed
  • cd frontend && npm run build — passed
  • git diff --check — passed

Not tested

  • Live backend-connected multi-Session browser flow

Direct Chat kept both per-session runtime caches and component-wide active
state. Project controls through the selected session identity and keep delayed
background sends from mutating the visible conversation.

Constraint: Preserve background Session execution and WebSocket delivery
Rejected: Close the previous Session socket on navigation | long-running Sessions must continue after the user switches away
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Never let background Session events update the visible composer without matching Agent and Session identities
Tested: Frontend node tests 90 passed; TypeScript and Vite production build passed
Not-tested: Live backend-connected multi-Session browser flow
@Y1fe1Zh0u

Copy link
Copy Markdown
Collaborator Author

Drone build 486 now clones and builds the upstream-head commit successfully. The remaining failure is in the current main migration baseline, before any frontend code is exercised: Alembic has two f061 heads, and fresh DB upgrade fails in f061_enterprise_info_tenant_id with DuplicateColumnError because enterprise_info.tenant_id already exists. This PR changes only four frontend files. The blocker is recorded in the v1.11.4 regression gate and should be cleared by a separate main migration repair.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant