test: increase timeout in vm-timeout-escape-queuemicrotask

[lundibundi]

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

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• commit message follows commit guidelines

/cc @nodejs/testing

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/29370/

[Trott]

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.

[Trott]

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.

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.

[Trott]

Though imo the test is inherently flaky and we probably won't be able to fix this completely.

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.

[addaleax]

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.

[jasnell]

I'm definitely +1 on removing the test

[jasnell]

LGTM but prefer removing it.

[jasnell]

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

[Trott]

I'm OK with fast-tracking this. Someone can submit a subsequent PR to remove if that's preferred.

[Trott]

Landed in 468bfd3