fix: Stale canvas events shown when switching between canvases without page refresh

[cursor]

Summary

Fixes #3504

When navigating between canvases without a page refresh, the UI displayed stale event data from the React Query cache instead of the latest state. WebSocket updates continued to work correctly, but the initial data rendered came from the cached canvas status response, which was outdated.

Root Cause

The issue had two contributing factors:

1. Global staleTime of 5 minutes — The React Query client is configured with a global staleTime: 5 * 60 * 1000. This meant cached canvas detail data (which includes status with lastExecutions, nextQueueItems, lastEvents) was considered "fresh" and served without triggering a background refetch when navigating back to a previously visited canvas.

2. Store initialization guard — The hasInitializedStoreRef in the workflow page prevented the node execution Zustand store from re-initializing after a background refetch completed with fresh data. Once the store was initialized from stale cache, it stayed stale.

Changes

web_src/src/hooks/useCanvasData.ts

• Set staleTime: 0 on useCanvas and useCanvasEvents hooks to override the global 5-minute default. This ensures a background refetch is always triggered when the query key changes (i.e., when canvasId changes), so fresh data is fetched on every canvas switch.

web_src/src/pages/workflowv2/index.tsx

• Immediate init + deferred re-init: When switching canvases, the store initializes immediately from cached data (so nodes render with their events right away — no loading gap). A pendingStoreReinitRef flag then allows exactly one re-initialization when the background refetch completes with fresh data.
• Reset on canvas switch: In the canvasId change effect, hasInitializedStoreRef is reset and pendingStoreReinitRef is set to true, enabling the re-initialization cycle for the incoming canvas.

How It Works

1. User navigates from Canvas B to Canvas A
2. canvasId change effect resets hasInitializedStoreRef = null and sets pendingStoreReinitRef = true
3. React Query serves cached Canvas A data with isFetching: true (background refetch triggered due to staleTime: 0)
4. Store initialization effect: ref mismatch → initializes immediately from cached data (no loading gap); since canvasFetching is true, pendingStoreReinitRef stays true
5. Background refetch completes: fresh Canvas A data arrives, canvasFetching becomes false
6. Store initialization effect: pendingStoreReinitRef is true and not fetching → re-initializes from fresh data, clears the flag
7. WebSocket events continue to merge correctly with the fresh baseline

  

[superplanehq-integration]

👋 Commands for maintainers:

• /sp start - Start an ephemeral machine (takes ~30s)
• /sp stop - Stop a running machine (auto-executed on pr close)

[forestileao]

/sp start

[superplanehq-integration]

✅ Ready.

Web: https://pr-3506-ephemeral.superplane.com
SSH: ssh -o StrictHostKeyChecking=no app@178.104.15.210
Logs: ssh -o StrictHostKeyChecking=no app@178.104.15.210 'cd superplane && make dev.logs.app'

[forestileao]

@cursoragent there is an UI thing that I don't like. The first node events are appearing after the nodes loaded. After the "Loading..."

[cursor]

Revised the approach to eliminate the loading gap the reviewer noticed. The new strategy:

• Before: Cleared the store and blocked initialization until the refetch completed, causing a visible "Loading..." flash where nodes appeared without their events.
• After: The store initializes immediately from cached data (so nodes render with events right away), then re-initializes once when the background refetch completes with fresh data. A pendingStoreReinitRef flag controls this one-shot re-initialization cycle, ensuring WebSocket updates aren't disrupted by subsequent refetches.

  

[forestileao]

/sp stop

[superplanehq-integration]

✅ Ephemeral machine has been terminated.