The screen shows old data

Five reasons a screen looks behind#

A tab that missed a release

The application is plain ES modules with no build step, so a tab that has been open since before a release is still running the files it fetched then. A reload is the whole fix.

A record still being written

A call closes its row and books its cost immediately, then runs the summary afterwards in the background. A row marked pending is mid-write, not stuck.

A derived value

Some state is derived from a log rather than stored beside it — live call control is computed from the guidance log, because pause, take over and release end in a state no single row describes. Derived values settle a tick behind their cause.

A deliberate snapshot

The voice settings shown against a past call are the ones that actually ran, snapshotted on the call. They are meant to disagree with the current configuration; that is what makes an old review readable.

Something genuinely did not save

The rarest of the five, and the only one that needs reporting. Confirm the other four first.

What Connect completed#

The write you are looking for almost always happened. Saves go through the service that owns the record, and the audit trail records the change with actor, target, and before-and-after states — so 'did this save' is a question with a recorded answer rather than a matter of opinion. Where the delay is a background digest, the durable parts finished first on purpose: the row and its cost are committed before the summary is attempted.

What Connect did not complete#

It did not push the change to a screen you already had open. There is no live refresh of an idle tab, so a change made elsewhere — by a colleague, by the engine, or by you in another window — appears when the screen next asks. It also did not warn you that the code in your tab is older than the code on the server.

What you can do#

1. Reload the page properly, not just re-navigate within the app.

   Result Moving between hash routes does not re-fetch the modules. A full reload does, and it settles the commonest cause immediately.

2. Look for a pending marker on the record before deciding it is wrong.

   Result A summary that has not appeared yet is being written. Waiting is the correct response, and re-running the action is not.

3. Check the timestamp on the record against the change you made.

   Result If the record's own time is later than your edit, the save happened and the screen is behind. If it is earlier, the save is the thing to investigate.

4. Open the same record from a different screen.

   Result Two screens reading the same canonical record will agree. Two screens disagreeing points at one of them rather than at the data.

What an administrator can do#

• Check whether the fetch for that mailbox is progressing at all. A cursor that has stopped moving looks exactly like stale data on every screen that reads mail.
• Check that the engine tick is running. Derived state, queue drainage and background digests all settle on a tick, and a stopped loop presents as everything being slightly out of date at once.
• Check whether a record was written into a provider table but never bridged across. The engine never reads provider tables, so anything stuck on that side is invisible to every screen.

When to escalate#

Escalate when a change is still missing after a full reload and a few minutes, and when the audit trail shows no entry for it — that combination means the write did not happen, rather than that it is not being shown. Escalate too if two screens disagree about the same canonical record after a reload, since one of them is reading something it should not be.

Questions#

Related#

• A screen is slow to load
• A screen is empty and should not be
• Deriving control state from the log instead of storing it
• Call summaries
• Mail is in the provider but not in Connect
• Troubleshooting