Skip to content

ERR_INTERNAL_ASSERTION: Unexpected module status 3 #58515

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
timokoessler opened this issue May 30, 2025 · 4 comments · May be fixed by #58598
Open

ERR_INTERNAL_ASSERTION: Unexpected module status 3 #58515

timokoessler opened this issue May 30, 2025 · 4 comments · May be fixed by #58598

Comments

@timokoessler
Copy link
Contributor

timokoessler commented May 30, 2025

Version

v24.1.0

Platform

Darwin MacBook-Pro 24.5.0 Darwin Kernel Version 24.5.0: Tue Apr 22 19:54:33 PDT 2025; root:xnu-11417.121.6~2/RELEASE_ARM64_T8122 arm64

Subsystem

module

What steps will reproduce the bug?

Create the following files:

instrument.mjs

import * as mod from "module";

mod.registerHooks({
  load(url, context, nextLoad) {
    return nextLoad(url, context);
  },
});

util1.js

const test2 = require("./util2");

util2.js

const test1 = require("./util1");

app.js

require("./util1");

console.log("Hello from app.js");

Run node --import ./instrument.mjs app.js

How often does it reproduce? Is there a required condition?

Always.

What is the expected behavior? Why is that the expected behavior?

No exception is thrown. It prints Hello from app.js.

What do you see instead?

node:internal/assert:17
  throw new ERR_INTERNAL_ASSERTION(message);
        ^

Error [ERR_INTERNAL_ASSERTION]: Unexpected module status 3.
This is caused by either a bug in Node.js or incorrect usage of Node.js internals.
Please open an issue with this stack trace at https://github.com/nodejs/node/issues

    at assert.fail (node:internal/assert:17:9)
    at ModuleJob.runSync (node:internal/modules/esm/module_job:314:12)
    at require (node:internal/modules/esm/translators:150:9)
    at Object.<anonymous> (/Users/timokoessler/Git/nodejs-module-hooks-bug/module-status-3/util2.js:1:15)
    at loadCJSModule (node:internal/modules/esm/translators:165:3)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:207:7)
    at ModuleJob.runSync (node:internal/modules/esm/module_job:306:39)
    at require (node:internal/modules/esm/translators:150:9)
    at Object.<anonymous> (/Users/timokoessler/Git/nodejs-module-hooks-bug/module-status-3/util1.js:1:15)
    at loadCJSModule (node:internal/modules/esm/translators:165:3) {
  code: 'ERR_INTERNAL_ASSERTION'
}

Node.js v24.1.0

Additional information

The issue does not occur in Node.js v24.0.1 or v23.11.1. I discovered this issue by importing hono, a popular web framework, while using registerHooks.

@bnoordhuis
Copy link
Member

"module status 3" is kEvaluating, when apparently kEvaluated is expected. b94f63b is most likely responsible. @joyeecheung?

@joyeecheung
Copy link
Member

Thanks for pinging.

I think this is again caused by the re-invented require in the ESM loader, which isn't capable of handling the cycle properly. As a workaround you can avoid the problematic CJS handling in the ESM loader by using --require to load the hooks, if it does not contain top-level await (locally that makes the repro go away):

node --require ./instrument.mjs app.js

It might be possible to put some band-aid on this to make this not show up again (e.g. allow kEvaluating when it's from reinvented require), the full fix would probably need to revert most of what's added by #47999 which at this point would need quite a bit more refactoring.

@timokoessler
Copy link
Contributor Author

Thank you for your replies and your work on Node.js. For me the main difference compared to the other issues I have already reported is that this one was introduced in v24.1.0. Fortunately, there has always been a workaround so far, so none of these issues is blocking us from continuing to work on a new alpha version of our library that uses registerHooks.

@joyeecheung
Copy link
Member

Fix (or band-aid) in #58598

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants