FR10 status screen waiting for its own diagnostic file

Developer captured those stages separately: the status reply is back, then the screen waits while the write finishes; we can reproduce that delay with the slow test destination, without changing the status source.

If they move writing out of the display path, ask what happens when the writer falls behind or cannot write at all, rather than giving it an unlimited queue.

Make missing diagnostic records visible too. A responsive screen is useful, but maintenance may later ask for history that was never saved. I would want the person using the display told when the record is incomplete, without confusing that with a failed status request.

Keep the original observation times when records finally reach the file; otherwise the queue can turn a delay in saving into an apparent delay in the equipment response.

What does the screen show during the pause, Sam? Is there any visible age on the last reading?

Last value just sits there, Elena, with no age; that's getting changed too, and Mia's point is in the file format review so the eventual write time won't replace the observation time.

Luis, I agree about missing history, but would you really show all the writer detail on the main screen? The operator needs to recognise stale status quickly, and another block of diagnostic information could make that harder

Two short states would do me: current reading unavailable, or diagnostic record incomplete. Different problems. Keep the detailed writer complaint somewhere I can open when I need it.

Isabel, Jane's split is close to what I meant. I want the loss visible, not the whole queue printed beside the status value. Maintenance can have the detail behind it. The screen still needs to make the reading's age easy to find.

We've agreed that split with the maintenance lead: age beside the reading, a separate record-incomplete indication, and writer detail behind it; developer is adding bounded buffering with an explicit gap when records cannot be retained.

Has the slow-destination test stopped freezing the display yet, Sam, or is the new writer still being put together?

New writer is in and the slow-destination test no longer blocks updates; denied writes and a deliberately full buffer also leave the display responsive, with the missing-record interval reported instead of silently pretending everything was saved.

Did they also test failed status reads while the writer is healthy, so the two new indications cannot stand in for each other?

Yes, that was in the same check set: failed read at startup, then failure after a good reading, both with healthy logging; current data becomes unavailable while the last observation stays labelled with its time, and the record-incomplete indication stays clear.

Thanks for the actual test results, Sam; I can see which problem each indication describes now, and the separate observation time is the bit I'd want preserved in the maintainer's examples.