-
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: Worker initialization failure test case #31929
test: Worker initialization failure test case #31929
Conversation
Cover the scenario fixed through nodejs#31621 Unfortunately there is no easy way to test this, in a cross-platform manner. So the approach is: - open a child process with ulimit restriction on file descriptors - in the child process, start few workers - more than the fd limit - make sure some workers fail, with the expected error type. - skip the test in windows, as there is no ulimit there.
} | ||
|
||
// Limit the number of open files, to force workers to fail | ||
let testCmd = 'ulimit -n 128 && '; |
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 not to go with something much smaller than 128
, like maybe 8
?
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.
@Trott, When I ran a simple node.js code, it created 30+ file descriptors. If I reduce the fd count to 8, it fails at arbitrary point without / before reaching worker creation.
} else { | ||
|
||
if (common.isWindows) { | ||
common.skip('ulimit does not work on Windows.'); |
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.
Maybe instead of skipping the test, just skip the ulimit
prefix? As written, I don't think the test won't fail if the error
event never happens, so the test might still be runnable under Windows?
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.
don't think the test won't fail if the error event never happens
I think this is an error in the test and therefore after it is resolved it will no longer be runnable on windows.
Also, it doesn't look like there is any equivalent for ulimit on windows so skip looks like the only way.
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.
@Trott , with respect to Windows - is there any merit in running a test that doesn't make any assertion ?
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.
The test still passes when the child process errors.
Locally, this test is failing for me. The error message I'm getting is Running CI to see if there are similar problems there or not..... |
AIX failed in CI (and there may be others as CI isn't finished at the time of this writing) and sure enough it failed with the |
} else { | ||
// Limit the number of open files, to force workers to fail. | ||
let testCmd = `ulimit -n ${OPENFILES} && `; | ||
|
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.
Nit:
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.
@lundibundi, thanks. Removed the extra line.
ping @Trott @nodejs/testing @nodejs/workers. |
Landed in 5b899d6 |
Cover the scenario fixed through #31621 Unfortunately there is no easy way to test this, in a cross-platform manner. So the approach is: - open a child process with ulimit restriction on file descriptors - in the child process, start few workers - more than the fd limit - make sure some workers fail, with the expected error type. - skip the test in windows, as there is no ulimit there. Refs: #31621 PR-URL: #31929 Reviewed-By: Denys Otrishko <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
Cover the scenario fixed through #31621 Unfortunately there is no easy way to test this, in a cross-platform manner. So the approach is: - open a child process with ulimit restriction on file descriptors - in the child process, start few workers - more than the fd limit - make sure some workers fail, with the expected error type. - skip the test in windows, as there is no ulimit there. Refs: #31621 PR-URL: #31929 Reviewed-By: Denys Otrishko <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
Cover the scenario fixed through #31621 Unfortunately there is no easy way to test this, in a cross-platform manner. So the approach is: - open a child process with ulimit restriction on file descriptors - in the child process, start few workers - more than the fd limit - make sure some workers fail, with the expected error type. - skip the test in windows, as there is no ulimit there. Refs: #31621 PR-URL: #31929 Reviewed-By: Denys Otrishko <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
Cover the scenario fixed through #31621 Unfortunately there is no easy way to test this, in a cross-platform manner. So the approach is: - open a child process with ulimit restriction on file descriptors - in the child process, start few workers - more than the fd limit - make sure some workers fail, with the expected error type. - skip the test in windows, as there is no ulimit there. Refs: #31621 PR-URL: #31929 Reviewed-By: Denys Otrishko <[email protected]> Reviewed-By: Anna Henningsen <[email protected]>
Cover the scenario fixed through
#31621
Unfortunately there is no easy way to test this, in a
cross-platform manner. So the approach is:
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes