Summary

Add a self-healing fallback in session-composer-state that detects running question tool parts in message parts when the questionRequest() memo is empty, and re-fetches the pending question list from the backend via sdk.client.question.list().

Why

The question dock relies exclusively on sync.data.question to render, which is populated by two paths:

1. Bootstrap: sdk.question.list() called once at startup
2. SSE events: question.asked real-time push

If the SSE event is lost (stream disconnect, transient error, reconnect gap), the question data never enters the frontend store. The dock never renders, the model waits forever for an answer, and the session appears stuck — even though the backend question is still pending and the message parts already contain the question tool in running state.

This was observed in a real session where the model called the question tool, the backend dispatched it (state = running), but the frontend never showed the question dock. The session froze with no way to recover.

Related Issue

None.

Human Review Status

Pending.

Review Focus

• The fallback effect logic in session-composer-state.ts lines 32–89: correct detection of running question parts, proper guard against re-fetch loops, correct store update via sync.set + reconcile
• Whether scanning the last 5 messages is sufficient and performant

Risk Notes

• The fallback only activates when there is a mismatch (running question part exists but no question request in store). It is a no-op under normal conditions.
• questionRefetchInflight prevents duplicate fetches but is module-scoped (shared across session switches). This is intentional — re-fetches are rare and a single inflight guard is sufficient.
• The fix does not address the root cause (SSE event reliability). A follow-up should consider event replay on reconnect.

How To Verify

Typecheck: passes (npx tsc --noEmit --project packages/app/tsconfig.json)
Existing tests: 7/7 pass (session-composer-state.test.ts)
Event reducer tests: 13/13 pass (event-reducer.test.ts)
Manual: the fallback activates when a running question tool part exists but questionRequest() is undefined

Screenshots or Recordings

Not applicable — no visible UI change. The fix ensures the question dock appears when it should.

Checklist

• Human review status is stated above as pending
• This PR has type, scope, and priority labels, or I requested maintainer labeling
• I described the review focus and any meaningful risks
• I listed the relevant verification steps and the key result for each
• I did not introduce unrelated refactors, dependencies, generated files, or file changes beyond the stated scope
• I considered macOS and Windows impact — no platform-specific changes
• I called out docs, release notes, dependencies, permissions, credentials, deletion behavior, generated content, or local file changes when relevant — none
• I reviewed the final diff for unrelated changes and suspicious dependency changes
• I am targeting dev, and my PR title and commit messages use Conventional Commits in English

Architectural Follow-up

This fix treats the symptom (missing question data) at the UI layer. The root cause is that the SSE event stream has no replay/recovery mechanism. Consider:

1. Event replay on reconnect: client sends last-seen event ID, server replays missed events. This fixes the problem for all event types (question, permission, session status, etc.)
2. Parts as source of truth: message parts are persisted and loaded via message sync (not SSE-dependent). The question dock could derive its state from parts directly, using events only as a "new data available" signal.
3. Polling fallback at the sync layer: rather than each UI component adding its own fallback, the sync layer could periodically reconcile its event-driven state against the backend API.

Summary by CodeRabbit

• Bug Fixes
  • Improved session composer stability: automatically detects and recovers missing or incomplete question data by refetching pending questions, preventing potential data loss and ensuring questions remain available during session composition. Refetching is protected against duplicate requests and silently handles transient errors to avoid user disruptions.