Flow Studio
Polling Fallback
When the SignalR WebSocket connection cannot be established or fails permanently after all reconnection attempts, Flow Studio automatically switches to REST API polling every 2 seconds. This ensures execution monitoring works even in restrictive network environments.
When Polling Activates
Polling activates automatically when:
- The initial WebSocket connection fails (e.g., WebSockets are blocked by a proxy)
- Reconnection attempts exhaust all retry delays (1s, 2s, 5s, 10s)
- The browser network monitor detects the WebSocket was closed with a non-recoverable error
useExecutionPolling
// useExecutionPolling.ts
export function useExecutionPolling(executionId: string, enabled: boolean) {
useEffect(() => {
if (!enabled) return;
const interval = setInterval(async () => {
const status = await fetch(
`/api/v1/process-engine/executions/${executionId}/status`
).then(r => r.json());
// Update store with polled status
updateStoreFromPolledStatus(status);
// Stop polling when execution is terminal
if (['completed', 'failed', 'cancelled'].includes(status.status)) {
clearInterval(interval);
}
}, 2000);
return () => clearInterval(interval);
}, [executionId, enabled]);
}
Polling Limitations vs SignalR
| Aspect | SignalR (WebSocket) | Polling (REST) |
|---|---|---|
| Latency | <100ms event delivery | 0–2000ms (depends on poll timing) |
| Log streaming | Real-time per-entry | Batched log retrieval per poll |
| Network overhead | Low (keep-alive pings only) | Higher (HTTP round-trip every 2s) |
| Node status updates | Event-driven, exact timing | Snapshot per poll, may miss rapid transitions |
Polling Shows "Live updates unavailable"
When polling is active, a warning banner appears in the Observer Panel. Node status still updates correctly, but rapid successive status changes (e.g., a node that completes in under 2s) may appear to skip directly to completed without showing the running state.