jonathansudhakar1 opened a new issue, #40992: URL: https://github.com/apache/beam/issues/40992
### What happened? `TestPersistBundle_ResidualResumeDelay/parks_with_hold_and_schedules` in the Prism engine is flaky. The test was added in #39849. It failed on master in the "Go tests" workflow on 2026-11-03: https://github.com/apache/beam/actions/runs/41695459870 (commit 26f3d47cc16) ``` --- FAIL: TestPersistBundle_ResidualResumeDelay (0.30s) --- FAIL: TestPersistBundle_ResidualResumeDelay/parks_with_hold_and_schedules (0.00s) elementmanager_continuation_test.go:370: residual release scheduled 5.000001877s after persisting, want within (0, 5s] ``` It reproduces locally on master (b0c68c4a4f7). On macOS/arm64 with Go 1.26, it failed 13 times in 20,000 runs: ``` cd sdks && go test ./go/pkg/beam/runners/prism/internal/engine/ \ -run 'TestPersistBundle_ResidualResumeDelay/parks_with_hold_and_schedules' -count=20000 ``` **Cause:** the test compares a millisecond-precision release time against a nanosecond-precision start time. The runner code is correct; only the test's bound is wrong. - The test takes `before := time.Now()` and checks that `fireAt.ToTime().Sub(before)` is in `(0, delay]` ([test L343-L371](https://github.com/apache/beam/blob/b0c68c4a4f7f9a87f87220b7413d14e9d0a17b9b/sdks/go/pkg/beam/runners/prism/internal/engine/elementmanager_continuation_test.go#L343-L371)). - `PersistBundle` computes `fireAt` as `emNow.Add(r.Delay)` ([elementmanager.go L971](https://github.com/apache/beam/blob/b0c68c4a4f7f9a87f87220b7413d14e9d0a17b9b/sdks/go/pkg/beam/runners/prism/internal/engine/elementmanager.go#L971), [L812-L825](https://github.com/apache/beam/blob/b0c68c4a4f7f9a87f87220b7413d14e9d0a17b9b/sdks/go/pkg/beam/runners/prism/internal/engine/elementmanager.go#L812-L825)). - With `EnableRTC` (as in this test), `emNow` is `mtime.Now()`, which truncates to milliseconds ([mtime L67-L69](https://github.com/apache/beam/blob/b0c68c4a4f7f9a87f87220b7413d14e9d0a17b9b/sdks/go/pkg/beam/core/graph/mtime/time.go#L67-L69)). - `emNow` is read slightly *after* `before`. If a millisecond boundary falls between the two reads, `emNow` is later than `before`, and `until` comes out a few microseconds above `delay`. **Suggested fix:** take `after := time.Now()` once `PersistBundle` returns, and check `fireAt` against `[mtime.FromTime(before).Add(delay), mtime.FromTime(after).Add(delay)]`. That is the exact range of possible release times, so the test stays strict. I'm planning to submit a PR with this fix. ### Issue Failure Failure: Test is flaky ### Issue Priority Priority: 2 (backlog / disabled test but we think the product is healthy) ### Issue Components - [ ] Component: Python SDK - [ ] Component: Java SDK - [x] Component: Go SDK - [ ] Component: Typescript SDK - [ ] Component: IO connector - [ ] Component: Beam YAML - [ ] Component: Beam examples - [ ] Component: Beam playground - [ ] Component: Beam katas - [ ] Component: Website - [ ] Component: Infrastructure - [ ] Component: Spark Runner - [ ] Component: Flink Runner - [x] Component: Prism Runner - [ ] Component: Hazelcast Jet Runner - [ ] Component: Google Cloud Dataflow Runner -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
