Fix duplicate fetchComplete when require() re-enters a shared dep's fetch

[robobun]

Fixes oven-sh/bun#30493.

Repro

require('./app.js') where app.js directly imports shared.js and also transitively through a.js / b.js → barrel.js → shared.js, where shared.js imports a synthetic builtin (e.g. import path from 'path'). On Linux debug: ASSERT(m_status == Status::Fetching) in ModuleRegistryEntry::fetchComplete. On Darwin: deadlock.

Root cause

When require() of an ESM graph reaches a module whose status is Fetching, hostLoadImportedModule's BUN_JSC_ADDITIONS inline path (added to drive the fetch/makeModule pipeline synchronously) calls makeModule, then mapEntry->fetchComplete(record) and modulePromise->fulfillPromise(record) directly.

The original async path had already queued moduleRegistryFetchSettled for the same entry. That handler checks modulePromise->status() != Pending and bails — good. But it runs makeModule before the check and attaches ModuleRegistryModuleSettled to the new makeModulePromise, which still fires as a separate microtask. moduleRegistryModuleSettled has no corresponding bail-out: it calls entry->fetchComplete(record) a second time (with a different record, from the redundant parse). In debug the assertion trips; in release the entry's record silently gets swapped to a stale duplicate that other modules never linked against.

Actually the real sequence in the repro: the inline sync path is the source of the duplicate makeModule. When hostLoadImportedModule enters the inline branch at JSModuleLoader.cpp:712 (fetchPromise already Fulfilled, modulePromise still Pending), it calls makeModule → fetchComplete inline. The moduleRegistryFetchSettled reaction that was queued earlier by the async pipeline already made its own makeModulePromise and attached ModuleRegistryModuleSettled. That settled callback then runs and tries fetchComplete on an already-Fetched entry.

Fix

Mirror the modulePromise->status() != Pending bail from moduleRegistryFetchSettled into moduleRegistryModuleSettled. The inline path has already produced a valid record and resolved the module promise; the queued copy's record is an unreachable duplicate parse.

Gated on USE(BUN_JSC_ADDITIONS) since VM::m_synchronousModuleQueue is Bun-only.

Verification

• Reproduced ASSERT(m_status == Status::Fetching) with current WebKit HEAD + Bun built locally.
• Applied the guard; the Bun regression test test/regression/issue/30493.test.ts (in the accompanying Bun PR) passes.
• test/js/bun/resolve/require-esm-*.test.ts and test/js/node/module/require-extensions.test.ts remain green.

[robobun]

Duplicate of #217. Same fix, same reasoning; closing this one.

[robobun]

Duplicate of #217 — same fix. Different tree of reproducers (this one came via bun#30493, diamond ESM through a barrel where shared.js imports node:path; #217 came via bun#30281, react + @mui/material). Same underlying bug: moduleRegistryModuleSettled missing the symmetric modulePromise->status() != Pending guard.

[coderabbitai]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 488c0859-dcda-4cf1-8641-3a2e1033164c

📥 Commits

Reviewing files that changed from the base of the PR and between 88b2f7a and eb3878a.

📒 Files selected for processing (1)

• Source/JavaScriptCore/runtime/JSMicrotask.cpp

Disabled knowledge base sources:

• Linear integration is disabled

You can enable these sources in your CodeRabbit configuration.

---

Walkthrough

This PR adds a guard check in moduleRegistryModuleSettled that prevents duplicate module settlement handling. When hostLoadImportedModule completes synchronously and settles a module promise, a queued microtask copy may still execute; the new check detects this and returns early to avoid redundant processing.

Changes

Module Promise Synchronous Re-entry Guard

Layer / File(s)	Summary
Early Return Guard for Pending State Source/JavaScriptCore/runtime/JSMicrotask.cpp	In moduleRegistryModuleSettled, check if modulePromise is still pending before proceeding; return early if already settled to prevent duplicate handling after synchronous re-entry from hostLoadImportedModule.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}