Repository navigation
[Failing Test]: AsyncWrapperTest.testBufferStopsAcceptingItems flaky on Windows #40448
Description
What happened?
AsyncWrapperTest.testBufferStopsAcceptingItems in sdks/java/core fails intermittently in Java Unit Tests (windows-latest) with java.lang.AssertionError: expected:<5> but was:<0>. It passes on Linux and macOS and on reruns.
Seen on PRs that do not touch sdks/java/core:
- [Spark 4] Support stateful ParDo in Structured Streaming via transformWithState #40281, https://github.com/apache/beam/actions/runs/37522104330
- [Spark 4] Filter late data against the key's previous watermark in the streaming stateful ParDo #40447, https://github.com/apache/beam/actions/runs/37613796171
The test depends on thread timing, an earlier flakiness fix was #38970.
Issue Failure
Failure: Test is flaky
Issue Priority
Priority: 2 (default / most bugs should be filed as P2)
Issue Components
- Component: Java SDK
Activity
Retrigger CI, AsyncWrapperTest flaky on Windows (apache#40448)
tkaymak commentedon Oct 7, 2026
Related: #40397 tries to address the same failure at
AsyncWrapperTest.java:678(expected:<5> but was:<0>) by raising the DoFn sleep to 1000ms and polling until the buffer count reaches 5. That still depends on timing, and the poll can return as soon as the 5th item is buffered, before the remaining producers have actually been throttled.I'm working on a deterministic fix that gates
BasicDofnwith aCountDownLatchand waits on all producer futures before asserting the buffer count. It also coverstestBufferCount,testBufferWithCancellation,testLongItemandtestSlowDuplicates, which have the same sleep based race since #38970.tkaymak commentedon Oct 7, 2026
It failed in 3 of 3 Windows runs so far, the third on the #40447 retrigger with
expected:<5> but was:<1>: https://github.com/apache/beam/actions/runs/37615492472Make AsyncWrapperTest deterministic (#40448) (#40449)
[Spark 4] Filter late data against the key's previous watermark in th…