-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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: add coverage for napi_cancel_async_work #12575
Conversation
4929d21
to
d4ea33d
Compare
adding test coverage for napi_cancel_async_work based on coverage report
d4ea33d
to
a73a991
Compare
NAPI_CALL_RETURN_VOID(env, napi_get_global(env, &global)); | ||
napi_value result; | ||
NAPI_CALL_RETURN_VOID(env, | ||
napi_call_function(env, global, callback, 0, nullptr, &result)); |
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.
napi_make_callback?
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.
Good point, I had re-used code from the other test in the file, but in this case it should be napi_make_callback
#if defined _WIN32 | ||
Sleep(2000); | ||
#else | ||
sleep(2); |
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.
Is this duration guessed? I would assume we could get away with something shorter…
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.
Yes I just chose a time that I thought would be long enough. Its a trade off between how long the test runs and potentially flaky failures.
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.
On my machine 1s is fine as well, but I'd lean towards leaving at 2s as I'd rather avoid risking flaky failures.
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 think @nodejs/testing has a general guideline that tests should not take longer than 1 second to run (which makes sense, we have thousands of tests…), that’s why I’m asking
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.
ok changed to 1s
@addaleax Pushed change to update to napi_make_callback |
CI run as I'd like to make sure timing works across platforms: https://ci.nodejs.org/job/node-test-pull-request/7635/ |
ok going to land this since I think I have addressed @addaleax's comment about time and there are 2 approvals. |
OS failure was not related, starting new CI run to confirm. - new OSX job https://ci.nodejs.org/job/node-test-commit-osx/nodes=osx1010/ |
CI re-run due to infra issues: https://ci.nodejs.org/job/node-test-pull-request/7693/ |
arms failures in new run seem to be infra issues and not related. |
2nd CI run good, arm failures were infra issues, landing. |
Landed as 1d96803 |
adding test coverage for napi_cancel_async_work based on coverage report PR-URL: #12575 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>
adding test coverage for napi_cancel_async_work based on coverage report PR-URL: nodejs#12575 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net>
adding test coverage for napi_cancel_async_work based
on coverage report
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
test, n-api