test: increase timeout in vm-timeout-escape-queuemicrotask - #31966
test: increase timeout in vm-timeout-escape-queuemicrotask#31966lundibundi wants to merge 1 commit into
Conversation
Sorry, something went wrong.
It looks like under high load the loop isn't even started and therefore successfully finishes without 'escaping'. After increasing the timeout during parallel run of the test failure rate decreased from 15/1000 to 0/1000.
Sorry, something went wrong.
|
Since this is only failing on Raspberry Pi devices, perhaps another solution to consider is to increase the multiplier in platformTimeout() for armv6 and/or armv7 devices? Then it only slows down the test on Raspberry Pi. Just a suggestion. Not blocking the change proposed here if it's preferred/easier/whatever. |
Sorry, something went wrong.
Maybe even consider adding an options object for platformTimeout() that allows individual tests to specify custom multipliers? Then the tests can still be super fast on fast machines without straining the limits of slower machines, but also without having to tune a single multiplier for all test cases. This one needs a bigger multiplier? OK, fine, have a bigger multiplier that only affects this test. That kind of thing. |
Sorry, something went wrong.
As a known-issue test, it is indeed inherently flaky. If the issue ever gets fixed, it will be flaky in the other direction which is probably preferable: It will usually fail if there's a bug, but will always pass in the bug's absence. Since that failure will (typically) be cross-platform, we can probably safely assume it would be caught in CI. In other words, if the known issue ever gets fixed, the test is (probably) fine. But as it is now, yeah, there might be no reasonable way to completely de-flake it short of fixing the bug so it's not a known-issue test anymore. |
Sorry, something went wrong.
|
Realistically, this bug is just never going to be fixed without major changes to V8 and worker.terminate() is a reasonable equivalent for most use cases. I’d be good with just deleting the test, tbh. |
Sorry, something went wrong.
|
I'm definitely +1 on removing the test |
Sorry, something went wrong.
jasnell
left a comment
There was a problem hiding this comment.
LGTM but prefer removing it.
Sorry, something went wrong.
|
Also, I'd like to see if we can fast track this because it is repeatedly causing failures for me in CI and it's painful. Please 👍 if you agree to fast track |
Sorry, something went wrong.
|
I'm OK with fast-tracking this. Someone can submit a subsequent PR to remove if that's preferred. |
Sorry, something went wrong.
It looks like under high load the loop isn't even started and therefore successfully finishes without 'escaping'. After increasing the timeout during parallel run of the test failure rate decreased from 15/1000 to 0/1000. PR-URL: #31966 Refs: #25529 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
It looks like under high load the loop isn't even started and therefore successfully finishes without 'escaping'. After increasing the timeout during parallel run of the test failure rate decreased from 15/1000 to 0/1000. PR-URL: #31966 Refs: #25529 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
It looks like under high load the loop isn't even started and therefore successfully finishes without 'escaping'. After increasing the timeout during parallel run of the test failure rate decreased from 15/1000 to 0/1000. PR-URL: #31966 Refs: #25529 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
It looks like under high load the loop isn't even started and therefore successfully finishes without 'escaping'. After increasing the timeout during parallel run of the test failure rate decreased from 15/1000 to 0/1000. PR-URL: #31966 Refs: #25529 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
It looks like under high load the loop isn't even started and therefore successfully finishes without 'escaping'. After increasing the timeout during parallel run of the test failure rate decreased from 15/1000 to 0/1000. PR-URL: #31966 Refs: #25529 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
It looks like under high load the loop isn't even started and therefore
successfully finishes without 'escaping'. After increasing the timeout
during parallel run of the test failure rate decreased from 15/1000 to
0/1000.
This will not fix the issue but should at least decrease its failure rate. Though imo the test is inherently flaky and we probably won't be able to fix this completely.
Refs: #25529
Checklist
/cc @nodejs/testing