Repository navigation
Flaky test: ScheduledExecutorsTest.testscheduleWithFixedDelay #20503
Description
This issue was generated automatically by Claude Code (Anthropic's AI coding agent) running a scheduled CI-triage routine on behalf of @FrankChen021. Analysis and suggested fixes are AI-produced; please verify before acting on them.
Status: Fix PR #20526 open
Subject: ScheduledExecutorsTest.testscheduleWithFixedDelay (processing, unit tests (25, S*))
Failures: 1 · First seen: 2026-10-06 · Last seen: 2026-10-06
Root cause
The test records startTime with System.currentTimeMillis() before scheduling a task with a 100 ms initial delay, then asserts the first start offset is strictly > 100. ScheduledThreadPoolExecutor fires on System.nanoTime() and can run the task exactly on time, so the millisecond-truncated wall-clock difference is often exactly 100 (the failure message is was: 100 in all four surefire attempts). The failing commit (#20479) only changes EmbeddedKafkaSupervisorTest, and the same S* job passed on the neighbouring master commits.
Suggested fix
Relax the lower bound to firstTaskStart >= 100 (or measure with System.nanoTime() and allow a few ms of tolerance, e.g. >= 95) in ScheduledExecutorsTest.testscheduleWithFixedDelay.
Occurrences
Failed push-triggered master jobs only. The daily triage routine adds one row per new failed job.
| Date | Commit | Job | Failure log | Detail | Reported in |
|---|---|---|---|---|---|
| 2026-10-06 | 205b50f (#20479) | unit tests / unit tests(main) (25, S*) / test-jdk25-[S*] |
job 112071715470 | First task should start at approximately initial delay (100ms), was: 100; failed all 4 attempts |
Activity
ykisana commentedon Oct 8, 2026
I think System.nanoTime() is a more robust fix for this. I can get a PR out for this.