-
Notifications
You must be signed in to change notification settings - Fork 30k
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 flaky test-resolve-async #17957
test: fix flaky test-resolve-async #17957
Conversation
CI: https://ci.nodejs.org/job/node-test-pull-request/12392/ (green) |
ada4921
to
766322d
Compare
FWIW, if the |
@Trott good point, I think this test actually doesn't need the (I think the reason |
testResolveAsync().then(common.mustCall(() => { | ||
called = true; | ||
})); | ||
testResolveAsync().then(() => (called = true)); |
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.
Any reason for the parentheses here instead of the seemingly-more-idiomatic curly braces?
|
||
setTimeout(common.mustCall(() => { assert(called); }), | ||
common.platformTimeout(20)); | ||
setTimeout(() => assert(called), common.platformTimeout(50)); |
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.
My usual comment: I'd prefer the assert(called)
be wrapped in curly braces to make it clear that there is no intention of returning a value here. I suspect I'm on the losing end of this particular unimportant style debate. :-P
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.
I don't have a strong preference so I've gone ahead and changed it.
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.
LGTM
PR-URL: nodejs#17957 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yuta Hiroto <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]>
PR-URL: #17957 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yuta Hiroto <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]>
PR-URL: #17957 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yuta Hiroto <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]>
PR-URL: #17957 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yuta Hiroto <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]>
PR-URL: #17957 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Yuta Hiroto <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Luigi Pinca <[email protected]> Reviewed-By: Michael Dawson <[email protected]> Reviewed-By: Ruben Bridgewater <[email protected]>
As I understand it, this test doesn't require theLooks like timeout might be needed after all, let's see if slightly higher setting will do.setTimeout
and can do just fine withsetImmediate
.This should fix the flakiness seen in https://ci.nodejs.org/job/node-test-commit-linux/15333/nodes=alpine37-container-x64/tapResults/
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
test