You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm hoping someone can shed some light on the following issues that we've been seeing (only in CI) surrounding Tinypool and memory.
Not every run, but more frequently than we like, the following error gets thrown and causes our builds to fail;
node:internal/event_target:1011
process.nextTick(() => { throw err; });
^
RangeError [Error]: WebAssembly.instantiate(): Out of memory: wasm memory
Emitted 'error' event on Tinypool instance at:
at EventEmitterReferencingAsyncResource.runInAsyncScope (node:async_hooks:203:9)
at Tinypool.emit (file:///src/xxx/node_modules/tinypool/dist/esm/index.js:60:31)
at Worker.<anonymous> (file:///src/xxx/node_modules/tinypool/dist/esm/index.js:566:30)
at Worker.emit (node:events:513:28)
at Worker.[kOnErrorMessage] (node:internal/worker:298:10)
at Worker.[kOnMessage] (node:internal/worker:309:37)
at MessagePort.<anonymous> (node:internal/worker:205:57)
at MessagePort.[nodejs.internal.kHybridDispatch] (node:internal/event_target:736:20)
at MessagePort.exports.emitMessage (node:internal/per_context/messageport:23:28)
error Command failed with exit code 1.
The very frustrating thing is that this only appears to happen when the build is run in our CI environment, as locally the tests pass with flying colours every time.
We've been trying to step around this problem for a while in our journey to migrate from Jest to vitest, and one of the attempts we had was to run with threads: false in our configuration file. This exposed some tests where we weren't cleaning up fully (due to the lack of isolation) which was handy, but that didn't seem to fix the problem in CI either.
We also thought that it might be a lack of resources on our side, as we run a bunch of other tests in parallel with vitest. So we ran the vitest tests on their own as a build step and that hasn't seem to fix the problem either.
I'd love to do more investigation on this problem, as I do really love vitest and the main driving factor for us doing this migration was the out-of-box support for WebAssembly (which we are starting to utilise more heavily in our frontend).
Any input on this would be fantastic, and I'm happy to do more digging/provide more info if its needed.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi
I'm hoping someone can shed some light on the following issues that we've been seeing (only in CI) surrounding Tinypool and memory.
Not every run, but more frequently than we like, the following error gets thrown and causes our builds to fail;
The very frustrating thing is that this only appears to happen when the build is run in our CI environment, as locally the tests pass with flying colours every time.
We've been trying to step around this problem for a while in our journey to migrate from Jest to vitest, and one of the attempts we had was to run with
threads: false
in our configuration file. This exposed some tests where we weren't cleaning up fully (due to the lack of isolation) which was handy, but that didn't seem to fix the problem in CI either.We also thought that it might be a lack of resources on our side, as we run a bunch of other tests in parallel with vitest. So we ran the vitest tests on their own as a build step and that hasn't seem to fix the problem either.
I'd love to do more investigation on this problem, as I do really love vitest and the main driving factor for us doing this migration was the out-of-box support for WebAssembly (which we are starting to utilise more heavily in our frontend).
Any input on this would be fantastic, and I'm happy to do more digging/provide more info if its needed.
Thanks
Beta Was this translation helpful? Give feedback.
All reactions