[lazerg]

listOnTimeout decides a timer is due, then runs the next tick queue left by the previous timer, then fires the timer it already picked. If a tick cleared and re-armed that same timer object, it fires right away and the new timeout is lost. Since #64254 reuses the socket's Timeout in setStreamTimeout, a socket.setTimeout() from such a tick hits this (timer.refresh() from a tick already did). Now the timer is checked again after the ticks run and skipped when it is no longer at the head of the list or no longer due.

Fixes: #67047

[github-actions]

Caution

AgentScan found account activity patterns that may be consistent with automation. This is a heuristic, not proof that this pull request was opened by an agent or violates policy. AI-assisted contributions are permitted, but automated tooling must not open pull requests without advance approval, and contributors must personally understand, test, verify, and take responsibility for every submitted change. See the AgentScan analysis, AI use policy, and automation policy for additional context.

[lazerg]

Caution

AgentScan found account activity patterns that may be consistent with automation. This is a heuristic, not proof that this pull request was opened by an agent or violates policy. AI-assisted contributions are permitted, but automated tooling must not open pull requests without advance approval, and contributors must personally understand, test, verify, and take responsibility for every submitted change. See the AgentScan analysis, AI use policy, and automation policy for additional context.

okay and?

[frimodig]

The fix matches the one suggested in #67047, but the test doesn't reliably fail without it. Over 50 runs per version in the official Docker images:

• v24.22.1: 46 fail, 4 pass
• v26.12.1: 46 fail, 4 pass
• v24.18.1 (last good): 50 pass

Using the timings from the issue's repro makes it fail every time:

-        socket.setTimeout(50);
+        socket.setTimeout(500);
...
-    }), 1);
-    socket.setTimeout(1);
+    }), 300);
+    socket.setTimeout(300);

With these, it failed 50 of 50 runs on v24.22.1 and v26.12.1, and passed 50 of 50 on v24.18.1.

This is only tested empirically. I don't know why the original timings (1 ms timers, re-armed to 50 ms) sometimes pass on an affected version.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.65%. Comparing base (640ce85) to head (cc1f25f).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #67051      +/-   ##
==========================================
- Coverage   90.66%   90.65%   -0.01%     
==========================================
  Files         797      797              
  Lines      278268   278272       +4     
  Branches    53521    53524       +3     
==========================================
- Hits       252280   252277       -3     
- Misses      16382    16384       +2     
- Partials     9606     9611       +5     

Files with missing lines	Coverage Δ
lib/internal/timers.js	100.00% <100.00%> (ø)

... and 26 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[lazerg]

Thanks, I switched the test to the issue's timings in cc1f25f. Without the fix it failed 339 of 340 runs here (the one pass was while the machine was under heavy load), and with the fix it passes.

[lazerg]

The test-macOS failure is not from this change. The runner stopped in the middle of the OpenSSL build, before any tests ran.