Troubleshoot missing real-time updates

Formist uses a space-scoped Server-Sent Events channel so changes made by another account can update open lists, details, Proposals, notifications, and Meetings without a manual refresh.

Quick checks

1. Confirm both users are viewing the same space and record.
2. Wait for the current save or approval request to finish; an optimistic local change is not yet a server event.
3. If one browser updates and another does not, reload the stale browser once. A successful reload with still-missing live updates points to the event stream rather than the data write.
4. Check that the frontend has a backend API base and that the browser can keep an EventSource connection open with credentials.

How reconnection works

The frontend creates one channel for the active space, subscribes to needed event types, and reconnects with capped backoff after a drop. Switching spaces closes the old channel. After a dropped stream reconnects, Formist requests an authoritative space refresh so events missed during the gap do not leave the screen stale. Proxies must allow long-lived SSE responses and must not buffer them indefinitely.

Proposal changes use both the event and a server refetch: a Pending or Applied update refreshes the Proposal queue and the affected space data. Messages and Files are loaded lazily, so Formist refreshes those lists only after the corresponding view or link data has been requested. An unsaved local field intentionally remains in the open form instead of being overwritten by another account's update.

Report useful evidence

Record the operation, affected record, two account roles, approximate time, and whether a refresh showed the correct state. Browser console messages beginning with [events] help distinguish channel creation, scope update, and reconnect failures.