The following tests needs to be reenabled for asan and tsan:

  - jstests/aggregation/accumulators/internal_js_reduce.js
  - jstests/core/query/map_reduce/mr_bigobject.js
  - jstests/core/query/map_reduce/mr_bigobject_replace.js

  - jstests/sharding/query/javascript_heap_limit_wasm.js

—

jstests/sharding/query/javascript_heap_limit_wasm.js is tagged tsan_incompatible because the WASM store-limiter OOM path involves an allocation inside a signal handler, which TSan flags as async-signal-unsafe.

Precise failure chain:

1. Wasmtime's store limiter denies a memory.grow call from SpiderMonkey
2. SpiderMonkey's allocator receives -1, calls MOZ_CRASH(...) which in the WASM binary compiles to a WASM unreachable instruction
3. Wasmtime's JIT emits a native trap instruction (ud2/udf) for unreachable; executing it raises SIGILL
4. Wasmtime's sigaction-registered SIGILL handler fires; it reads from the trap registry and (depending on Wasmtime version / config) may capture a backtrace via backtrace::Backtrace::capture(), which calls malloc
5. TSan detects malloc called from a signal handler (whose owner thread may hold TSan's internal shadow-memory lock) → TSan aborts

Options to fix, in order of preference:

1. Upstream Wasmtime fix (proper long-term fix): File an issue at https://github.com/bytecodealliance/wasmtime asking for the SIGILL handler to be made async-signal-safe — either by pre-allocating per-thread trap info before entering JIT code, or by suppressing backtrace capture when backtrace feature is enabled under TSan. After the fix lands upstream, bump MongoDB's Wasmtime version pin.

1. TSan suppression (short-term workaround): Add an entry to etc/san/tsan.suppressions for the specific Wasmtime signal handler frame that allocates. Requires running the test under a TSan binary to capture the exact frame name (something like wasmtime::runtime::vm::traphandlers::...). This unblocks TSan CI without upstream work but doesn't fix the underlying issue.

1. Test restructuring (avoids the signal path): Instead of OOM-ing through the store limiter (which triggers the SIGILL → signal handler path), test the heap limit via a direct jsHeapLimitMB cap that causes SpiderMonkey to throw a JS-level exception before calling memory.grow. This avoids the signal handler entirely but tests a slightly different code path (JS GC limit, not store limiter).

Acceptance criteria: javascript_heap_limit_wasm.js passes in the sharding_tsan or equivalent TSan suite without the tsan_incompatible tag.