You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I took some time to investigate this test failure more thoroughly. Looks like it used to fail prior to fixing the other test, so it seems we've uncovered another flaky test by resolving the previous one 😄
Joke aside. Looks like when the machine is heavily overloaded, it would have a very significant impact on scheduling / firing timers over and over. Especially this failure - here
duration_ms: 3147.927
exitcode: 1
severity: fail
stack: |-
diff: 1002 <------- first
diff: 1003 <------- second
diff: 2426
The actual interval between second interval and the first interval is only 1ms difference which seems pretty wild to me.
I believe the original intent of the test was to check if setInterval allows for a tolerance of 200ms between each timer when under pressure, but the results are proving to be unpredictable.
I would consider to dig into timers a bit more and at the moment I would purpose to mark the test as flaky on the appeared platforms.
I've been monitoring the reliability report for nearly a week, and I've noticed that flakiness frequently occurs on these three platforms, but not on others (so far):
ubi81_container-x64-1
ubuntu2204_sharedlibs_container-x64-7
ubuntu2204_container-armv7l-1
It could be a coincidence, but I believe we can label them as flaky. I'm open to alternative suggestions.
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 240 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.
Activity
test: deflake test/pummel/test-timers.js
test: deflake test/pummel/test-timers.js
test: deflake test/pummel/test-timers.js
lpinca commentedon Oct 15, 2024
It is still flaky.
https://ci.nodejs.org/job/node-test-commit-arm/55372/nodes=ubuntu2204-armv7l/testReport/junit/(root)/pummel/test_timers/
jakecastelli commentedon Oct 16, 2024
Thanks for reporting 🙏 I will take a look soon
jakecastelli commentedon Oct 17, 2024
I took some time to investigate this test failure more thoroughly. Looks like it used to fail prior to fixing the other test, so it seems we've uncovered another flaky test by resolving the previous one 😄
Joke aside. Looks like when the machine is heavily overloaded, it would have a very significant impact on scheduling / firing timers over and over. Especially this failure - here
The actual interval between second interval and the first interval is only 1ms difference which seems pretty wild to me.
I believe the original intent of the test was to check if
setIntervalallows for a tolerance of200msbetween each timer when under pressure, but the results are proving to be unpredictable.I would consider to dig into timers a bit more and at the moment I would purpose to mark the test as flaky on the appeared platforms.
Happy for any suggestions! @nodejs/timers
jakecastelli commentedon Oct 22, 2024
I've been monitoring the reliability report for nearly a week, and I've noticed that flakiness frequently occurs on these three platforms, but not on others (so far):
It could be a coincidence, but I believe we can label them as flaky. I'm open to alternative suggestions.
test: deflake test/pummel/test-timers.js
test: deflake test/pummel/test-timers.js
github-actions commentedon Apr 27, 2026
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
github-actions commentedon May 27, 2026
This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 240 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.