Skip to content

module: throw error when re-runing errored module jobs #58957

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

Merged
merged 1 commit into from
Jul 9, 2025

Conversation

joyeecheung
Copy link
Member

@joyeecheung joyeecheung commented Jul 4, 2025

Re-evaluating an errored ESM should lead to rejecting the rejection again - this is also the case when importing it twice. In the case of retrying with require after import, just throw the cached error.

Drive-by: add some debug logs.

Fixes: #58945

@nodejs-github-bot
Copy link
Collaborator

Review requested:

  • @nodejs/loaders

@nodejs-github-bot nodejs-github-bot added esm Issues and PRs related to the ECMAScript Modules implementation. needs-ci PRs that need a full CI run. labels Jul 4, 2025
Re-evaluating an errored ESM should lead to rejecting
the rejection again - this is also the case when importing
it twice. In the case of retrying with
require after import, just throw the cached error.

Drive-by: add some debug logs.
Copy link

codecov bot commented Jul 4, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.10%. Comparing base (8173d9d) to head (d2455ef).
Report is 45 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main   #58957      +/-   ##
==========================================
+ Coverage   90.09%   90.10%   +0.01%     
==========================================
  Files         640      640              
  Lines      188462   188452      -10     
  Branches    36962    36972      +10     
==========================================
+ Hits       169786   169796      +10     
+ Misses      11404    11376      -28     
- Partials     7272     7280       +8     
Files with missing lines Coverage Δ
lib/internal/modules/esm/loader.js 96.37% <100.00%> (+0.01%) ⬆️
lib/internal/modules/esm/module_job.js 97.51% <100.00%> (+0.02%) ⬆️

... and 46 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@joyeecheung joyeecheung added the request-ci Add this label to start a Jenkins CI on a PR. label Jul 7, 2025
@github-actions github-actions bot removed the request-ci Add this label to start a Jenkins CI on a PR. label Jul 7, 2025
@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot
Copy link
Collaborator

}, {
message: 'test',
});
})().catch(common.mustNotCall());
Copy link
Contributor

@aduh95 aduh95 Jul 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We want to catch never-settling promises (EDIT: I've opened #58992 to enforce that at the linter level, so it's fine to land it as is, I can update the other PR once this one has landed)

Suggested change
})().catch(common.mustNotCall());
})().then(common.mustCall());

Any reason not to use TLA/.mjs here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the promise never settles the test should just fail with exit code 13. On the other hand using catch with must not call would surface unwanted rejections.

If we use .mjs then we need to use createRequire() - I'd rather keep the plain require() since that's the more commonly hit path if some boilerplate is inevitable.

Copy link
Contributor

@aduh95 aduh95 Jul 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the promise never settles the test should just fail with exit code 13

I think that's the case only for TLA, which we are not using here; you can convince yourself by adding a await new Promise(() => {}) at the top of the IIFE and see the test still passes.


assert.rejects(import('../fixtures/es-modules/throw-error.mjs'), {
message: 'test',
}).catch(common.mustNotCall());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here

Suggested change
}).catch(common.mustNotCall());
}).then(common.mustCall());

Comment on lines +9 to +11
await assert.rejects(import('../fixtures/es-modules/throw-error.mjs'), {
message: 'test',
});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: it would be interesting to validate we catch the exact value being thrown, not just one with the same message.

@nodejs-github-bot
Copy link
Collaborator

@aduh95 aduh95 added author ready PRs that have at least one approval, no pending requests for changes, and a CI started. commit-queue Add this label to land a pull request using GitHub Actions. labels Jul 9, 2025
@nodejs-github-bot nodejs-github-bot removed the commit-queue Add this label to land a pull request using GitHub Actions. label Jul 9, 2025
@nodejs-github-bot nodejs-github-bot merged commit 793a279 into nodejs:main Jul 9, 2025
64 checks passed
@nodejs-github-bot
Copy link
Collaborator

Landed in 793a279

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. esm Issues and PRs related to the ECMAScript Modules implementation. needs-ci PRs that need a full CI run.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

require(esm) with top level error taints future await import(esm) swallowing errors
5 participants