A client following the event stream keeps a cursor, and the server refuses that cursor once it has fallen too far behind. Nothing tells the client how close it is to that point, so the first sign of trouble is the refusal itself — after which the only recovery is a full resync.
What is missing
The stream exposes no watermark: neither the oldest sequence still retained, nor the distance between it and the cursor the client holds. A client can therefore not tell the difference between "comfortably up to date" and "one quiet hour away from being rejected".
Why it matters on the desktop side
The choice a client wants to make is when to pay for a resync. Knowing it is near the edge, it can resync deliberately — on a network it likes, while the app is idle, before the user notices. Discovering it at the moment of refusal means resyncing right then, whatever else is happening.
It also makes the failure mode legible in reports. Today a refused cursor and a genuinely broken stream look the same from outside.
What would help
Anything that lets the client compute its own margin, in decreasing order of usefulness:
- The oldest retained sequence alongside the current head, so the client subtracts and knows its slack.
- Failing that, the retention window as a documented, queryable value rather than an implementation detail.
- Failing that, a warning threshold on the stream itself — an event saying "this cursor is close to expiry" before the refusal.
The first is the most useful and probably the cheapest, since it is a value the retention logic already knows.
A client following the event stream keeps a cursor, and the server refuses that cursor once it has fallen too far behind. Nothing tells the client how close it is to that point, so the first sign of trouble is the refusal itself — after which the only recovery is a full resync.
What is missing
The stream exposes no watermark: neither the oldest sequence still retained, nor the distance between it and the cursor the client holds. A client can therefore not tell the difference between "comfortably up to date" and "one quiet hour away from being rejected".
Why it matters on the desktop side
The choice a client wants to make is when to pay for a resync. Knowing it is near the edge, it can resync deliberately — on a network it likes, while the app is idle, before the user notices. Discovering it at the moment of refusal means resyncing right then, whatever else is happening.
It also makes the failure mode legible in reports. Today a refused cursor and a genuinely broken stream look the same from outside.
What would help
Anything that lets the client compute its own margin, in decreasing order of usefulness:
The first is the most useful and probably the cheapest, since it is a value the retention logic already knows.