[Arkex-ai]

Summary

The Windows log writer test can fail when a busy CI runner delays the writer or observer, even with batching disabled. The same 200 ms assertion failed on two upstream runs without a change to the logger.

Closes #2012.

Technical changes

• Observe finite batching waits in the extracted production writer while forwarding the real Windows condition-variable call.
• Keep the exact-output check and bounded completion. The other four cases and the production logger are unchanged.

Validation

• On Windows LLVM, all five cases passed at a9bf239 on main c09e0ac.

• Adding 350 ms at worker startup reproduced the old off failure. All five cases passed with the revised fixture under the same delay.

• Forcing a positive batching wait in the off case was rejected by the new assertion. The four other cases still passed.

• This is a Windows test-only change. No gameplay or package behavior changed.

• The fork and upstream Windows source jobs both passed test_log_batch.py in 15.5 s. Both finished at 324 passed, 1 failed, 22 skipped. The sole failure was the skeleton bake timeout tracked in fix(build): run offline bake with portable zstd and Clang 18 #1954. Upstream source run.

Current-head fork check	Result
Source suite	Failed

[Arkex-ai]

I found overlap with #2013. This draft checks the writer's actual batching wait while preserving the exact-output assertion. It passed locally with a 350 ms writer-start delay and rejected a forced batching wait. The targeted test also passed in both hosted Windows runs. #2013 instead keeps the timing threshold and takes the fastest of three deliveries.

The only failure in our hosted Windows runs was the skeleton bake timeout. #1954 passed the full Windows source suite with the bake tests still enabled. If you'd like to keep the release CI changes together, feel free to use the fixture change from here in #2013. I'll keep this draft while the overlap is resolved so the fixes aren't both landed.

[Arkex-ai]

Closing this draft now that #2013 has landed its fix for the same assertion. The direct wait-observer test remains here if the timing check starts flaking again.