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 |
|
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
startTimewithSystem.currentTimeMillis()before scheduling a task with a 100 ms initial delay, then asserts the first start offset is strictly> 100.ScheduledThreadPoolExecutorfires onSystem.nanoTime()and can run the task exactly on time, so the millisecond-truncated wall-clock difference is often exactly100(the failure message iswas: 100in all four surefire attempts). The failing commit (#20479) only changesEmbeddedKafkaSupervisorTest, and the sameS*job passed on the neighbouring master commits.Suggested fix
Relax the lower bound to
firstTaskStart >= 100(or measure withSystem.nanoTime()and allow a few ms of tolerance, e.g.>= 95) inScheduledExecutorsTest.testscheduleWithFixedDelay.Occurrences
Failed push-triggered master jobs only. The daily triage routine adds one row per new failed job.
unit tests / unit tests(main) (25, S*) / test-jdk25-[S*]First task should start at approximately initial delay (100ms), was: 100; failed all 4 attempts