-
Notifications
You must be signed in to change notification settings - Fork 29.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test: fix cluster-disconnect-handles flakiness #4009
test: fix cluster-disconnect-handles flakiness #4009
Conversation
const req = protocol.serialize({ command: 'continue' }); | ||
debugClient.write(req); | ||
} | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't it be better to rewrite the protocol.onResponse logic to wait for the break event first before sending the continue command?
Thanks for looking into this, by the way. Looks like this might fix #3907.
8301a40
to
d90a4f5
Compare
@bnoordhuis updated using |
Sometimes the test was timing out because the worker process remained stuck in the breakpoint and didn't exit. This could happen because the continue was sent before the breakpoint was set. If that's the case, with this change, a new continue command is sent so the worker process can end.
d90a4f5
to
1226417
Compare
Thanks Santiago, landed in 8677627. |
Sometimes the test was timing out because the worker process remained stuck in the breakpoint and didn't exit. This could happen because the continue was sent before the breakpoint was set. If that's the case, with this change, a new continue command is sent so the worker process can end. PR-URL: #4009 Reviewed-By: Ben Noordhuis <[email protected]>
Sometimes the test was timing out because the worker process remained stuck in the breakpoint and didn't exit. This could happen because the continue was sent before the breakpoint was set. If that's the case, with this change, a new continue command is sent so the worker process can end. PR-URL: #4009 Reviewed-By: Ben Noordhuis <[email protected]>
Sometimes the test was timing out because the worker process remained stuck in the breakpoint and didn't exit. This could happen because the continue was sent before the breakpoint was set. If that's the case, with this change, a new continue command is sent so the worker process can end. PR-URL: #4009 Reviewed-By: Ben Noordhuis <[email protected]>
Sometimes the test was timing out because the worker process remained stuck in the breakpoint and didn't exit. This could happen because the continue was sent before the breakpoint was set. If that's the case, with this change, a new continue command is sent so the worker process can end. PR-URL: #4009 Reviewed-By: Ben Noordhuis <[email protected]>
Sometimes the test was timing out because the worker process remained stuck in the breakpoint and didn't exit. This could happen because the continue was sent before the breakpoint was set. If that's the case, with this change, a new continue command is sent so the worker process can end. PR-URL: #4009 Reviewed-By: Ben Noordhuis <[email protected]>
Sometimes the test was timing out because the worker process remained stuck in the breakpoint and didn't exit. This could happen because the continue was sent before the breakpoint was set. If that's the case, with this change, a new continue command is sent so the worker process can end. PR-URL: nodejs#4009 Reviewed-By: Ben Noordhuis <[email protected]>
Sometimes the test was timing out because the worker process remained stuck in
the breakpoint and didn't exit. This could happen because the continue was sent
before the breakpoint was set. If that's the case, with this change, a new
continue command is sent so the worker process can end.
It fixes for me the following error I was receiving in a
Jessie 64bit
box: