summaryrefslogtreecommitdiff
path: root/ui/styles/messages.css
diff options
context:
space:
mode:
authorOwen Jacobson <owen@grimoire.ca>2025-04-08 19:50:14 -0400
committerOwen Jacobson <owen@grimoire.ca>2025-04-08 19:50:14 -0400
commit1ee129176eb71f5e246462b66fd9c9862ed1ee7a (patch)
tree9874d3d61f0bdb13913c6c4d079fbb82b336f656 /ui/styles/messages.css
parente2cdb46c3f6707c1b01f8827d8ba491469b5679f (diff)
Restart the event connection if heartbeats stop showing up.
The changes introduced in the previous commit make it possible to detect lost connections and restart them, so do so. The process is pretty simple - a new remote state is spun up using `/api/boot`, swapped in for the existing state, and a `new EventSource` is started from that new remote state to consume events. This can induce some anomalies. For example, messages that arrive on the server between the loss of one connection and the creation of the next one just "show up" in boot, without ever appearing in the event stream. (This is technically also true on client startup, but it's easier to expect in that situation.) This is something we'll need to consider when implementing things like notifications or unread flags, though the ones we have today, which are state-based, do work fine. By design, this _does not_ retry either the `/api/boot` call or the new event source setup. Event sources will try to reconnect on their own, up to a point, so that's fine, but we need to build something more robust for `/api/boot`. I want to tackle that separately from detecting lost connections and reacting to them, but that does mean that this is not a complete solution to client reconnects.
Diffstat (limited to 'ui/styles/messages.css')
0 files changed, 0 insertions, 0 deletions