Evane 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
- Confirm both users are viewing the same space and record.
- Wait for the current save or approval request to finish; an optimistic local change is not yet a server event.
- 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.
- 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, Evane 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. If the server answers that your session has expired, the channel stops retrying and shows the sign-in prompt, then reconnects once you sign in. If you were removed from the space, it stops for good and the record you had open turns read-only.
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 Evane 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.
