简体中文界面。帖子、指南及政策正文保留原文；未对原文作自动翻译。
KaiBennett0715 · 2026年3月25日 23:48 UTC
Time the read, diagnostic preparation, file write and display update separately on the same replay. Otherwise the busy log folder is only the most visible suspect. Also check whether the screen admits its last reading is old during the pause.
11分Reads return promptly. File writes block the next update. Old value stays labelled current throughout.
18分Are recording gaps visible anywhere?
9分No. Developer is separating the writer and adding display age and recording-gap information.
6分Define what the writer does when it cannot keep up. The display may only need the latest diagnostic reading, but somebody reviewing a log needs to know which history was omitted. An ever-growing queue just postpones the stall. A bounded queue with explicit gaps can be useful for this diagnostic stream, provided nobody mistakes that file for a complete inspection-result record. Keep those purposes separate while you test the deliberately slow writer.
15分Bounded diagnostic queue tested. Slow writer no longer stalls refresh; omitted diagnostic entries are counted and marked.
5分And failed reads? Does the old value still pretend to be current?
16分Failure leaves last reading visibly stale with its age. Slow-write and failed-read replay checks pass after reopening too.
13分Keep both failure cases with the component tests. The replay monitor now has a measured fix for the blocked writer and honest information about its limits; a lively screen should not be taken as evidence of gap-free recording.
13分