Re-enable the temporarily disabled circleci tests.#26996
Conversation
|
Locally esm-integration is broken, we'll see if it's the same here... |
Commit 48b0616 optimized worker thread postMessage commands by replacing string literals (like 'load') with integer constants (like CMD_LOAD = 1). However, the ES Module worker bootstrap loader script, pthread_esm_startup.mjs, was missed in that cleanup and kept the hardcoded check msg.data.cmd == 'load'. As a result, when running in WASM_ESM_INTEGRATION mode, the startup loader silently ignored the numeric commands sent by the parent thread. This caused worker threads to never load the main module and prevented them from signaling readiness, resulting in an infinite hang during initialization of pthreads. To resolve this, define the thread command constants in the central, shared parseTools.mjs compile-time utility context, so that they are globally accessible during standalone preprocessing. This enables the ESM worker bootstrap script to cleanly preprocess and evaluate the numeric CMD_LOAD constant macro, fixing the hang.
Commit 347da58 enabled falling back to other engines in wasm64 requirement helpers if Node.js is missing, but changed the behavior when no capable engine is found from skipping to failing. This broke Deno- only testing environments where the wasm64 test variant was executed via crossplatform-only targets but failed due to Deno not being recognized as an eligible wasm64 JS engine. To resolve this, check for Deno and allow it as a valid wasm64 JS engine inside require_wasm64 helper.
| executor: linux-python | ||
| environment: | ||
| EMTEST_SKIP_NEW_CMAKE: "1" | ||
| EMTEST_SKIP_WASM64: "1" |
There was a problem hiding this comment.
Does bun not support wasm64?
There was a problem hiding this comment.
It probably does, but trying it out quickly it was failing. wasm64 tests use to be skipped on bun, so this really just restores the old behavior. I think we should enable in another PR.
There was a problem hiding this comment.
How were they skipped before? In general I try not to ever implicitly skip any tests. But maybe this case was one that I fixed recently ? (i.e. did I remove the implicit skipping?)
There was a problem hiding this comment.
It's the same reason as the deno commit in this PR. This commit changed how it worked. We use always skip deno and bun before that.
There was a problem hiding this comment.
I see yes, fair enough. They we being auto-skipped before.
2 participants
No description provided.