commit-teardown.test.ts crashes with SIGABRT (mutex lock failed: Invalid argument) on Deno macOS CI

[kriszyp]

Summary

test/commit-teardown.test.ts ("Async commit completion vs. worker env teardown") crashes
the repro child process with SIGABRT on Deno + macos-latest CI, with:

libc++abi: terminating due to uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument

This is a native (C++) crash — pthread_mutex_lock returning EINVAL, which on libc++'s
std::mutex means the mutex was already destroyed (or never initialized) when a thread tried
to lock it. It reproduces in the fixture's normal worker-terminate-mid-commit-stream scenario
(test/fixtures/fork-commit-teardown.mts), i.e. exactly the lifecycle race the test exists to
catch (env teardown racing the shared per-database commit thread) — just not the specific
env-cleanup-hook / commit-completion-tsfn race the test's own comment describes, since that
path is guarded by commitMutex (see AGENTS.md "Commit execution"). Something else in the
teardown path is locking a mutex whose owning object has already been (or is concurrently
being) destroyed.

Evidence this is pre-existing and unrelated to any single PR's diff

Same test, same exact crash message, same "iteration=0" first-iteration failure, across three
unrelated PRs in the last 24h — none of which touch commit-teardown/commit-thread code:

PR / branch	run	ROCKSDB_JS_COMMIT_THREAD mode	job
#744 fix/park-timeout-coordinated-retry (VT park-timeout only)	30719858670	'2'	Test on Deno (macos-latest)
dependabot/npm_and_yarn/patch-b7a1a6d5c6 (dependency bump)	30665452962	'default'	Test on Deno (macos-latest)
fix/dropped-cf-write-poisons-env	30663991359	'2'	Test on Deno (macos-latest)

Hits both commit-thread modes (default single-lane and 2 two-lane), so it's not specific to
the two-lane pipeline. All three are macOS + Deno only in the runs observed so far (Node and Bun
macOS jobs passed alongside it in the same CI run for #744), though the fixture only runs 1
iteration on macOS/Windows (vs. 2 on Linux Node — see the test's iterations comment), so a
lower hit-rate on other runtime/OS combos on this evidence alone doesn't rule them out.

Likely relation to other open lifecycle issues

Same theme as #695 (env-cleanup-hook/registry teardown races) and #741 (worker-env teardown
corrupting the shared DBDescriptor's transactions under concurrent commits) — a third distinct
symptom in the same "shared DBDescriptor survives one env's teardown while another env is still
using it" hazard class, this time inside CommitWorker/commit-completion teardown rather than
OpenDB (#695) or TransactionHandle/RocksDB txn destruction (#741). Filing separately since the
crash site/mutex involved hasn't been isolated yet — needs a debug build + the ASan/Guard Malloc
procedure in AGENTS.md ("Debugging native heap corruption") to pin down which mutex.

Suggested next step

Root-cause with ASan (Linux) or Guard Malloc (macOS) per AGENTS.md, looping
fork-commit-teardown.mts directly (bypass vitest to get a clean native stack). Until then, a CI
retry stopgap for the affected job (matching the existing windows-latest retry pattern, precedent
in #695/#742) keeps this pre-existing race from blocking unrelated PRs.

Reported by Claude Sonnet 5 on behalf of @kriszyp, while triaging PR #744's CI failure.