Frame-loss lines in the log are a recovery counter

Synchronized data travels as a chain: every update the server sends names the update it sent before it, so a viewer that misses one notices immediately and asks for a fresh copy. That recovery has been in place for a while, and it works — but it writes a line to the log each time, and a large number of those lines has repeatedly been read as a large amount of lost data.

It is the opposite. Each line is a gap that was detected and already repaired. The data-sync architecture page now says so, and gives the two numbers that actually diagnose something: how often a single stream logs it, and whether a fresh copy ever follows. It also lists the log lines to read alongside it, because the cause is almost always something further upstream ending and re-establishing a subscription — not the chain itself.

Reconnecting…
The connection to the server was interrupted. Trying to restore it…
Trying again…
The connection could not be restored. Reloading the page…
The server was updated. Reloading the page to pick up the latest version.