It does. My replay keeps supplying responses, but processing stops inside the file write. Finally, something I can reproduce.

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.

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.

Can routine samples be dropped but error summaries kept? I don't need endless identical status lines.

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

@FelixBarnes0545 My setup originally queued its overflow warning through the writer that was already full, so the warning disappeared along with the samples it was meant to explain.

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

@FelixBarnes0545 I'll make logging health visible beside our monitor status. A moving display shouldn't quietly imply complete logs.

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

Written, currently. That's awkward. Our charts could make a disk pause look like a late robot response.

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.

The replay establishes that synchronous logging can stall this application. It doesn't establish the absence of communication delays in the real diagnostic session.

Right. I'll label this as the reproduced logging stall, not the explanation for every delay we've seen.

@FelixBarnes0545 I found queue depth helpful on my own monitor because it exposed a writer backlog that wasn't obvious from the size of the log file.

I still haven't established a reliable way for our display and logging to behave under storage delays. Reproducing the stall isn't a finished fix.

Fair. Reproduction gives you something to work on, but doesn't establish reliable behaviour under that delay.