Skip to content

fix(session): ignore stale workspace session loads#1277

Open
benjaminshafii wants to merge 1 commit intodevfrom
fix/windows-workspace-session-race
Open

fix(session): ignore stale workspace session loads#1277
benjaminshafii wants to merge 1 commit intodevfrom
fix/windows-workspace-session-race

Conversation

@benjaminshafii
Copy link
Copy Markdown
Member

Summary

  • drop stale loadSessions() results when the active client changed or the selected workspace root moved before the response came back
  • wire the existing scoped-root guard into the live session store so post-switch/new-workspace loads cannot overwrite the current workspace sidebar
  • keep the fix small and local to apps/app/src/app/context/session.ts

Why

The previous attempt focused on Windows path persistence, but your latest report points much more strongly to a race: after restart everything looks fine.

That lines up with the current code path: we already had shouldApplyScopedSessionLoad() in session-scope.ts and tests for stale loads, but context/session.ts never actually used that guard when applying a session.list() response.

So during a workspace create/switch, an older in-flight session load could finish after the new workspace had already become active and then replace the sidebar/session list with stale data. That can make the freshly created workspace look empty until restart.

What changed

  • apps/app/src/app/context/session.ts
    • capture the requested scope root up front
    • after session.list() returns, only apply the result if:
      • the client instance is still the same, and
      • the selected workspace root still matches the scope that was requested
    • otherwise log a sessions:load:stale debug event and drop the response

Verification

Ran from apps/app:

  • pnpm typecheck
  • pnpm test:session-scope

Notes

  • This PR supersedes the earlier path-persistence attempt: the stronger signal here is stale async state rather than persisted root mismatch.
  • I did not run the Docker + Chrome MCP flow because the reported bug is Windows-specific and this environment is macOS. To verify end-to-end on Windows, please create a new local workspace, confirm the starter sessions appear immediately, and create a new session without restarting the app.

New-workspace and workspace-switch flows can fire overlapping session loads while
the engine reconnects. We already had a scoped-root guard in session-scope.ts,
but the live session store never used it, so an older in-flight load could win
last and replace the new workspace sidebar with stale results.

Drop session-list responses when the active client changed or the selected
workspace root no longer matches the load that produced them. This keeps the
post-create workspace view stable until the correct workspace sessions arrive.
@vercel
Copy link
Copy Markdown

vercel bot commented Apr 1, 2026

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

Project Deployment Actions Updated (UTC)
openwork-app Ready Ready Preview, Comment Apr 1, 2026 2:47pm
openwork-den Ready Ready Preview, Comment Apr 1, 2026 2:47pm
openwork-den-worker-proxy Ready Ready Preview, Comment Apr 1, 2026 2:47pm
openwork-landing Ready Ready Preview, Comment, Open in v0 Apr 1, 2026 2:47pm
openwork-share Ready Ready Preview, Comment Apr 1, 2026 2:47pm

@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Apr 1, 2026

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

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