The replay reproduces the pause with no network involved. Incoming samples reach the parser steadily, but the display callback waits for each file flush. Disabling detailed writes removes that pause in the same replay.

That's a specific local finding. If you move writing to a queue, give the queue a bound and decide what happens when the disk can't keep up. Otherwise the display improvement can simply hide a memory problem until later.

I'd keep the screen and the saved trend requirements separate. Showing the latest sample may be fine for a current-status view, but a history used for diagnosis must identify anything it didn't retain. A smooth screen can make a broken trend look wonderfully healthy.

Isaac, yes. Our maintainers look back at the saved record after the event. They need gap and overflow information there, not only a warning that flashed on a screen nobody was watching.

We chose a bounded writer queue. On overflow the monitor records a visible loss interval and dropped-record count when writing resumes; it doesn't silently pretend the trend is continuous. Current display uses the latest timestamped sample and shows age.

Test a deliberately stalled writer, then recovery, using that same input. Check the queue bound, display age and saved loss information. Normal replay performance won't establish the overflow behaviour you just described.

And test closing while writes are pending. Decide whether shutdown drains within a bound or records an incomplete tail. Don't let the last part of a diagnostic session vanish behind a clean close message.

Sam, have those checks run now? Interested whether the saved gaps are as clear as the on-screen warning, especially after the writer recovers.

Yes. Slow and stalled writer replays stay within the queue bound, the display remains responsive with age visible, and the saved trend records the loss interval and count. Interrupted shutdown leaves an explicit incomplete-session marker. The maintainer accepted the logging change after reviewing those files.

That resolves the flush-blocked display path you reproduced. Keep the stage timing available for future incidents; this result doesn't mean a real communication delay could never happen, only that you now have a way to distinguish it.