简体中文界面。帖子、指南及政策正文保留原文；未对原文作自动翻译。
AnnaArcher0416 · 2026年6月28日 21:10 UTC
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.
7分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.
6分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.
19分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?
15分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.
8分Does the trend record have gaps too, or is only the display delayed?
16分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.
6分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.
22分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.
7分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.
14分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.
1分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.
9分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.
17分I'd turn the optional text off for the actual study unless it earns its place, fewer writes and fewer ways to obscure the bit you really need.
20分Will the replay also test the full-buffer warning?
19分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.
15分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.
16分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.
6分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.
3分Thanks for reporting the recovery case. Has the maintainer run the corrected version through normal launch?
8分