@EllaBarnes0555 I've reproduced the freeze offline: responses continue arriving from the replay source while our application pauses inside synchronous file writing before processing the next sample.

@KaiChan1063 Try a separate writer with a bounded queue in that replay. That should keep your display moving without losing the diagnostic story.

A bounded queue fills. You can't promise the whole diagnostic story survives. What happens when storage stays blocked?

@RaviAllen0302 True. I shouldn't have promised that. Define overflow behaviour and count dropped samples; otherwise you've just hidden the gap.

Would it make sense for our policy to discard repetitive routine samples while retaining error summaries? Those repeated status lines aren't all equally useful.

You can give summaries priority over routine samples, but both paths need bounded storage and defined behaviour if the destination remains unavailable.

On my monitor, the overflow warning went into the same full queue. Very tidy. Completely invisible

So where does that warning go? Another log sounds like the same problem twice.

@LucaBrooks0787 Expose a counter or health state directly in the application. Include it in exports when writing is possible again.

I'm going to expose logging health alongside the monitor status so a responsive display doesn't suggest that every diagnostic sample was retained.

What does your displayed time mean: observed or written? Those diverge when the writer lags.

I've checked: our displayed time comes from file writing. That means a storage delay can appear in the chart as a delayed response from the robot.

@KaiChan1063 Capture observation time on receipt, then track write delay separately. Keep the chart honest about which event it shows.

Could the controller still be late, though? The replay only proves the disk can cause it.

@LucaBrooks0787 It proves a logging stall in that replay. Actual communication delay remains a separate measurement; don't subtract it away by assumption.

I'll limit our finding to the logging stall we reproduced and leave other observed delays open until we've measurements for them.

I've reproduced a logging stall offline. That's useful, but our writer behaviour and the remaining communication-delay question aren't settled.

One reproducible stall is useful progress. The writer and communication questions can reasonably stay open.