Detailed logging coincides with our read-only FR5 diagnostic display freezing while the destination folder is busy. Cell controls are separate. I suspect file writes, but I have not separated communication delay from display delay. What timing evidence would settle which path is stuck?
Can you time the request, response receipt, log write and screen update separately? I would want to know whether new data stops arriving or arrives and then waits somewhere before display.
The current timing is one total for the polling routine. It includes logging and display preparation, so it cannot answer that. I have asked the developer to split those observations.
Replay saved replies into a deliberately slow test destination too, then you can make the file side awkward without depending on the controller to misbehave at the same moment.
What does the frozen screen say about its age, Anna? Actually, can someone arriving during the freeze tell it has stopped refreshing without having watched the last change?
No age shown. A green available indication can sit there unchanged. We have flagged that display limitation for users while the developer traces the delay; it is not an application control signal.
Ben Barnes, that's worth separating. A responsive screen and a complete trend are different requirements; I don't know whether Anna's detailed file is optional diagnostics or the record someone relies on.
The trend is needed for this maintenance study. Detailed text is optional. New timings show replies continue arriving while the display waits. The writer holds a shared lock during its file write, and the screen needs that lock to obtain a snapshot.
So not a slow controller in that captured case, the screen is queuing behind the writer; I'd keep the slow-destination replay as a regression test for the lock change.
Does the display age indicator use that same locked snapshot? It would be unfortunate to fix the wording and leave the warning waiting behind the operation it is meant to describe.
It would in the first proposal. Developer has changed that: the view calculates age from the last received snapshot it already owns. File I/O is being moved outside the shared-state lock. No test result yet.
What happens when storage stays slow long enough that the trend writer cannot keep up? Removing that lock does not by itself define whether queued records grow, get lost or stop the study.
Study owner requires an explicit recording failure, not silently missing trend points. The proposed bounded buffer will report that failure and mark the study record incomplete if exhausted. Optional diagnostic text can be dropped with its own count, separately labelled.
Sam, that can reduce load but Anna still needs the failure behaviour. Even with text off, somebody can disconnect or fill the destination. I'd avoid letting a quiet test become proof that recording cannot fail.
The slow-write replay now leaves the display refreshing. Forced buffer exhaustion raises Recording failed and marks the trend incomplete; optional-text drops have a different counter. We also tested delayed replies: age increases and the value becomes stale rather than remaining green.
How is a later successful write presented after that recording failure? I would not want it to erase the gap and make the same study look complete again.
It does not erase it. The incomplete status stays attached to that study, and starting another recording requires an explicit new study record. The test retained the gap even after the destination recovered.