debugger: wait for target startup before initialization - #64304
Conversation
|
Several previous attempts of deflaking were unsuccessful. |
Ok, I got it .Thanks ! |
88fe3e7 to
1e6cde7
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #64304 +/- ##
==========================================
- Coverage 90.31% 90.31% -0.01%
==========================================
Files 759 759
Lines 247646 248350 +704
Branches 46697 46871 +174
==========================================
+ Hits 223654 224288 +634
- Misses 15463 15473 +10
- Partials 8529 8589 +60
🚀 New features to boost your workflow:
|
|
@joyeecheung @trivikr Could you take a look at this? I believe this would fix the flaky tests that related to timou of macos ci |
|
@joyeecheung @trivikr Please take a look at this |
|
I think at the minimum the commit should explain why the previous flakes happen, and why the change is supposed to fix it? |
The debugger endpoint can accept a connection before the target has entered its startup wait. In that window,Runtime.runIfWaitingForDebugger may be handled too early, leaving the target waiting indefinitely. Use NodeRuntime.waitingForDebugger as a readiness handshake before initializing the debugger domains and releasing the target. Apply the handshake to both the interactive debugger and probe mode,and reject the wait if the session closes. Signed-off-by: Archkon <180910180+Archkon@users.noreply.github.com>
Debugger tests spawn a debugger client and target process, then wait for asynchronous CLI output through a shared test helper.Under high parallel load on macOS, process scheduling and inspector communication can delay progress beyond the existing 15-second timeout, causing intermittent failures across multiple debugger tests. Signed-off-by: Archkon <180910180+Archkon@users.noreply.github.com>
Run the debugger CLI in the per-test temporary directory so concurrent runs do not overwrite or remove the same node.cpuprofile file. Signed-off-by: Archkon <180910180+Archkon@users.noreply.github.com>
|
@joyeecheung I have tried stress test for all test/parallel/test-debugger-*x1000 with -j 16 and all passed And also select one of flaky tests to run 1 million times to check and before github aciton timeout no one would fail |
b85de2c to
aa1cfd8
Compare
|
I revert the two commit that fix the flaky test and you could see the parallel/test-debugger-exceptions would fail from time to time but this never fail at the previously stress test of 1 million times. Refs: https://github.com/Archkon/node/actions/runs/31153457092/job/92787764799 And you could download the diagostic infomation from artificat that I used to ix the timeout problem of all test-debugger-* tests on macos platform to review and inspect Refs: https://github.com/Archkon/node/actions/runs/31155360956/job/92793569004 You could see log like this for the race condtion of failed tests @joyeecheung Please evaluate this |
Trying to fix the test error that triggered at previous pr when run github action ci/cd
https://github.com/nodejs/node/actions/runs/28730483133/job/85195106458?pr=64301
Fixes: #64116
Fixes: #61762
Fixes: #64005