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.

@LuisBarnes0608 Move the replay's file writing behind a bounded queue and let a separate writer handle it. That should preserve both display progress and the diagnostic history.

Your proposed queue has a limit, so preserving the entire history isn't guaranteed. A persistent storage blockage needs an explicit overflow policy.

@GabrielBaker0453 You're right about my preservation claim. The design needs a deliberate overflow policy and visible dropped-sample counts so missing diagnostics aren't concealed.

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.

@LuisBarnes0608 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.

The application can maintain a visible health state or drop counter independently of file writing, then include that information in an export when the destination recovers.

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

Are you displaying when the application observed the sample or when the writer saved it? A delayed writer makes those different events.

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.

Record when the application receives the observation and measure the later write delay independently, making the chart's chosen time field explicit.

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

@OwenAbbott0051 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.

The replay establishes a logging stall, which answers what I needed to isolate. A completed fix still depends on continued processing with delayed storage and explicit reporting of diagnostic loss.

Your conclusion matches the replay, and the condition for completion covers both processing and diagnostic loss.