fix(session): poll sidebar session list via query cache to surface externally created sessions

[Formatted]

Summary

• Add visibility-aware polling to surface externally created sessions in the sidebar
• Sessions from automations, messaging bots (Slack/Telegram), and other clients now appear without manual refresh
• Uses TanStack Query caching system instead of raw useEffect + setInterval (as requested in closed PR fix(session): poll sidebar session list to surface externally created sessions #1551)

Changes

• New: session-list-cache.ts - Query key factory and useSessionListPolling hook for visibility-aware polling
• Modified: session-route.tsx - Lightweight session-only refresh callback + polling integration
• Session lists written to TanStack Query cache alongside imperative state
• Existing refreshInFlightRef dedup guard prevents overlapping calls
• Polls every 30s when tab is visible; fires immediately on visibility change

Problem

Automated runs, messaging bot sessions, and other externally created sessions were invisible in the sidebar until the user triggered an indirect refresh (e.g. renaming a session).

Solution

Added a lightweight polling hook backed by the TanStack Query caching system. The refreshSessionLists callback only re-fetches session lists (avoiding the heavy refreshRouteState work of re-resolving connections and workspaces).

Fixes #1262

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
openwork-landing	Ready	Preview, Comment, Open in v0	May 5, 2026 2:47am

[vercel]

@Formatted is attempting to deploy a commit to the Different AI Team on Vercel.

A member of the Team first needs to authorize it.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

[src-opn]

Requesting changes.

Code verification issue:

• apps/app/src/react-app/shell/session-route.tsx:565-587: refreshSessionLists only checks refreshInFlightRef.current but never sets an in-flight guard for its own polling work. If listSessions takes longer than the 30s interval, or if the tab becomes visible while a poll is already running, multiple session-list refreshes can overlap. The visibility event can also race with the existing visibility handler at session-route.tsx:728-732, causing the new lightweight refresh and full refreshRouteState() to run concurrently. This contradicts the PR description/comment that the existing guard prevents overlapping calls, and it can reintroduce the event-loop/network pressure this area is trying to avoid. Please add a dedicated polling in-flight guard, or reuse the existing guard consistently, and avoid double refreshes on visibility restore.

Verification performed:

• pnpm install --frozen-lockfile passed.
• pnpm --filter @openwork/app typecheck passed.
• pnpm --filter @openwork/app build passed.

[Formatted]

Addressed in 30183fe (on top of the merge with dev).

Changes vs. the original commit:

• Dedicated in-flight guard for the poller. Added pollSessionsInFlightRef and toggle it in try/finally inside refreshSessionLists so a slow listSessions call (or a visibility-triggered tick during an active poll) cannot overlap with itself. The check is now if (refreshInFlightRef.current || pollSessionsInFlightRef.current) return; — refreshInFlightRef is still respected so a full refreshRouteState blocks the lightweight poll, but the poller no longer relies on someone else's flag to gate its own re-entry.
• Removed the visibilitychange handler from useSessionListPolling. The session-route already wires up its own visibility handler that runs refreshRouteState (which re-fetches sessions via loadWorkspaceSessionsInBackground). Firing refetch from the polling hook on the same event was the double refresh the review flagged. The polling hook now relies on its 30s interval; visibility restore is handled by the route-level handler.
• Updated the JSDoc on useSessionListPolling to spell out that the caller must provide its own in-flight guard and that visibility restore is intentionally not handled here.

Verified locally: pnpm install --frozen-lockfile, pnpm --filter @openwork/app typecheck, pnpm --filter @openwork/app build all pass on the PR branch (the unrelated settings-route.tsx / messaging-view-state.ts typecheck errors that show up post-merge are present on pristine dev too).