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

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

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.

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

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

How do you expose an overflow warning if the logger is blocked? Would a second log just create another version of the same failure?

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

@LinAdams0096 The offline replay gives me one reproducible cause. I still need to establish the writer's behaviour and assess communication delays separately.

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