The read-only monitor freezes its display when the detailed log gets busy, then jumps through several updates at once. Cell controls are separate. I keep calling it a connection pause, but I haven't actually shown that the reads stopped. What should our software person measure before I start blaming the network again?
Can they time the read, file write and display update separately in one captured pause? Otherwise busy log folder is still a coincidence, not the location of the wait.
Put the diagnostic timing somewhere that doesn't wait on the same file writer. A small bounded trace in memory may be enough for the comparison. Then make any trace loss visible instead of silently running out of space.
And don't call the frozen display offline unless you actually have a failed connection check. Our green boxes already tell enough stories without adding an invented red one.
What does it show during the freeze now? A changing age since the last reading would tell me something; an unchanged last-seen time assumes I'm watching a clock too.
Just the old value and its timestamp. Nothing changes, including the clock drawn in that window. So a new age label in the same blocked update probably wouldn't move either.
Nathan, agreed. Theo, a separate writer may help if the file wait is on that loop, but it needs a bounded queue and a defined full-queue policy. Otherwise a frozen window can become an ever-growing memory problem.
Those need separate answers. A current display can use the newest reading while the diagnostic record has its own retention requirement. Who owns that requirement here?
Maintenance wants the diagnostic sequence around a pause, not an indefinitely growing archive. Software captured a case: read completed, file write waited, UI update followed it. They're proposing a separate bounded writer with visible recording gaps if it can't keep up.
That sounds worth testing against the agreed diagnostic needs. A visible gap is preferable to hidden loss, but maintenance still needs to decide whether that gap leaves enough evidence for the reason they're collecting it.
Maintenance agreed that missing samples must be shown and the trace can't be described as complete across a gap. Latest-value display is separate in the proposal. We aren't claiming every historical pause was the same file wait.
Can the offline replay test a slow writer and a failed read separately? That would show whether a display improvement accidentally hides genuine communication trouble.
Replay now keeps the UI updating with a slow writer, and queue saturation produces a recording-gap indication. Failed-read wording still looks like an old value with no warning, so that test is not passing yet.
Does the failed-read test include starting with no successful value? An old-value warning can't help the first request when there is no old value to show.
Keep both failing cases visible until they are handled. The writer change has answered a real problem, but the monitor still has to tell the truth when no fresh reading comes back.