FR5 monitor stalls while its diagnostic folder is busy

Only the file-line time. So my lovely diagnostic log may be measuring its own queue. I haven't established which stage actually waits.

Have the maintainer time request start and return, parsing, writer entry and exit, and display update separately, using a bounded trace that does not depend on the suspected writer.

A replay of saved replies could help too. Feed the same sequence with an ordinary writer and a deliberately delayed writer, then compare the displayed values and their observation times. That tests the application path without requiring the workshop folder to become busy on demand. I would still keep a failed or delayed read as a separate case. Otherwise a fix that makes the screen lively can look successful while it quietly presents old information as new

Unchanged value, no visible age. The file time is also used as the displayed time. I've asked the maintainer to separate the observation time from when the record finally gets written.

That time difference matters even if the writer turns out innocent. An old reading deserves its own old time, not the time the screen remembered to show it.

Agreed. The application should preserve when the reading was obtained and report current read failure explicitly. Writer health is another state, not a substitute for communication status.

Did the maintainer get usable stage timings for an actual pause yet, or is the replay the first comparison available?

Replay first. With the delayed writer, request processing waits before the next read is started and the display pauses too. That reproduces the application symptom, but doesn't establish every workshop pause had the same cause.

Is the proposed fix moving writes out of that path?

If it uses a queue, define its size limit and overflow behaviour. Moving the wait into an ever-growing queue can trade a visible pause for hidden memory growth and missing evidence later.

Yes, a bounded writer queue is proposed, Grace. Harish, maintenance wants visible notice of dropped diagnostic records rather than silent loss. That behaviour is still being reviewed with the queue limit.

Who needs to act on that notice, and can they distinguish it from a failed status read without your explanation?

Luca's question is practical. Maintenance may need the missing-record warning while the operator chiefly needs to know whether the current status is usable; they need not have equal prominence, but neither should disappear.

Maintenance owns the logging warning. The proposed operator view shows status unavailable after a failed read, with last-known time separate. We are checking that wording with someone who didn't write the monitor.

The offline version now passes delayed-writer, failed-read and good-then-failed cases. Queue overflow is visible. The workshop comparison remains unrun, and the read-only monitor is not being treated as a control signal.

Thanks. And a failure on the very first read? No old value available to lean on.

Included now, Grace. It starts unavailable and doesn't invent a last-known value. Still waiting on the workshop comparison before we issue the revised handover.