-
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: make test-tick-processor.js non-flaky #8542
Conversation
Wait for a sought-for symbol to appear instead of just hard-killing subprocesses at 2s timeout. Fix: nodejs#4427
cc @Trott |
cc @nodejs/testing |
If CI is green - I'd suggest stress-run for that particular test in this PR. |
if (common.isWindows || | ||
common.isSunOS || | ||
common.isAix || | ||
common.isLinuxPPCBE || | ||
common.isFreeBSD) { | ||
common.skip('C++ symbols are not mapped for this os.'); | ||
return; | ||
} else { |
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.
Did you mean to include the rest of the tests inside this else
block? Either that or the return
keyword has to be restored, I would think...
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.
Yikes! Fixed now.
Also, if this PR ends up fixing the test's flakiness across all platforms, I'm totally naming my next goldfish |
A test failure now will be a timeout as the test retries and retries and retries and never finds what it's looking for? (I am more than OK with that. Just making sure I understand the test and the intention.) |
@Trott your analysis is correct. |
Still some timeouts/failures. I wonder if splitting it into three test files would help so that:
|
It won't help, looks like you can't open a locked file on Windows. I wonder if we can use pipes for this. |
The newest version splits files into three and collects |
I think it should be generally ok, if we will increase allowed timeout values for new |
I'm not sure what you mean exactly. You mean the retry timeout? And for the Raspberry Pi devices only (because they look like the only ones failing right now, thankfully)? If so, we can probably set it to Would need run some stress tests but even as is, if this means the test are only flaky on the Raspberry Pi devices and not anywhere else, that's still a huge improvement! |
@Trott I meant the test timeout, it looks like the test is killed too early on pi's. |
Ah, yeah, that would be up to the @nodejs/build group I suppose. I think the timeout for Pi devices is already double or more that of most everything else, though. An alternative might be to skip some or all (depending on whether some or all are failing) of these three tests on Pi devices by checking |
@Trott this seems to be CPU bound to me. |
In that case, I guess long term, I'd like to see if @nodejs/build and @nodejs/testing would be OK with bumping the test timeout on the Raspberry Pi devices up. That might allow us to re-enable a handful of the other tests that we turned off for those devices. In the meantime, just to get this fixed until something like that can happen, would it be too much of a code smell (and would it even work) to check the |
@Trott I think it should be safer to just mark these tests as FLAKY on ARM. |
Sure, that works. The downside there is that it will also mark it flaky on the four ARM test platforms that aren't Raspberry Pi. But that seems acceptable to me. |
@Trott we don't have ARM-specific code for these features, so it should be safe. |
@Trott pushed an update that should supposedly mark these tests as FLAKY on arm only. |
LGTM |
@Trott I decided to re-run it to test FLAKY specifiers for the arch (we don't seem to use them anywhere else) |
Oh, yeah, the FLAKY test designation was ignored on Raspberry Pi for a while, IIRC. Might still be for all I know... Guess we're about to find out... |
@Trott it looks like it didn't quite work. Should we land this as it is and defer the rest to the @nodejs/testing ? |
I think that would be OK. |
If you want to be bold and bump up the Raspberry Pi devices from 3 minute timeout to 5 minute timeout, I think you just need to change the And if you really don't want to spend more time tweaking things just to accommodate Raspberry Pi, I can also understand that. :-| |
Landed in 5a17139, thank you! |
Checklist
make -j4 test
(UNIX), orvcbuild test nosign
(Windows) passesAffected core subsystem(s)
test
Description of change
Wait for a sought-for symbol to appear instead of just hard-killing
subprocesses at 2s timeout.
Fix: #4427