Reconnected, with an outdated booking board
A green connection indicator can make an old screen feel current. An imagined meeting-room app reveals the work between reconnecting and catching up.
The green light returns
Imagine a meeting-room booking app. A small room is free in the afternoon. You leave the board open and carry your laptop to another desk, losing Wi-Fi along the way.
The connection returns. An indicator in the corner turns green. The board is unchanged, so it seems safe to send everyone to the room that was empty a moment ago.
What if someone booked it while you were disconnected?
Two groups could meet at the door, each expecting the same room. One checked the current booking. The other trusted the green light.
The detail that stayed with me in Wonkook Lee’s realtime communication guide was separating connection status from synchronization status. Opening the connection again leaves work to do.
For this imagined app, I would start with the code that lights the indicator. Does the color mean we can talk to the server, or that we have checked the bookings currently on display?
People did not open the board because they wanted to discuss that distinction. They wanted an empty room.
The last thing you heard
SSE’s EventSource can attempt to reconnect and pass an existing last event ID to the server in Last-Event-ID. MDN and the HTML Standard describe that behavior.
The name can make resuming sound like a completed job. The server still needs to retain the events and replay the ones after that position.
In the booking example, saying ‘I received everything up to here’ does little if the server no longer remembers what happened next. A restored phone call does not automatically play the conversation you missed.
If the screen only helps people find a free room now, I would consider fetching the current board again. A history screen investigating who moved a booking needs the intervening changes too. Even within one app, recovery can mean different things.
Does fetching the board and then subscribing to updates finish the job? A booking could change in the gap between those operations.
For this app, I would consider a contract returning the board together with the log position it represents, then resuming changes after that position. Attaching a separately fetched latest position to an older board could mark something as caught up when it is not.
The handoff from replayed history to new notifications belongs in that contract as well. Adding a position marker does not, by itself, close every gap.
If the disconnection outlasts the retained history, the app should learn that too and check a fresh board. A missing stretch of data should not quietly become a completed synchronization.
Received, but not displayed
A connection can stay healthy while something else fails. Suppose an update arrives, but the code applying it to the board throws an error. The indicator is still green.
In the HTML Standard’s event processing sequence, the last event ID is updated before the event is dispatched to the application. That ID cannot be treated as a booking version the app successfully applied.
For this hypothetical board, I would want to track the version actually displayed. If the browser’s received position and the app’s applied position diverge, there is a reason to fetch again or start recovery.
Let one green light stand for all those states and someone may confidently walk to the room. ‘Connected; checking bookings’ gives them a reason to wait. A visible unknown can change a real decision.
I would also measure more than the time needed to open a connection. For this app’s purpose, the relevant interval runs from a confirmed booking to its application on the screen. Catch-up after a disconnection deserves a separate measurement.
Of course, checking the server does not guarantee the next moment will stay unchanged. Confirming a reservation still needs the server’s decision. A freshness indicator must not be mistaken for a successful booking.
If I were building this app, I would pause over one small message.
‘Connected again.’
And whether the board below it had been checked again too, before adding the next line.