-
Notifications
You must be signed in to change notification settings - Fork 30.9k
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
Node hard crash when importing napi module #57233
Comments
Looks like the issue is due to inspiredware/napi-build-utils#6 & prebuild/prebuild-install#203 but should one expect NAPI 10 to ship mid-LTS and cause breakages such as this? Its also missing from documentation https://nodejs.org/api/n-api.html#node-api-version-matrix |
That's a bug in that tool (bad version check), not in napi. The documentation omission seems like an oversight though. @nodejs/documentation - napi 10 is not mentioned in the docs/api/n-api.md version matrix in any release line. Are there plans to back-port it to v20.x or v18.x? |
I'd agree if a require in a try catch didn't segfault my app and thousands of users. Either a try catch should work or there should be no napi changes within an lts branch surely. I don't see how such a failure mode is acceptable even if technically the crash didn't happen in your code. |
It's not really up for the discussion. The tool you used did something wrong and miscompiled your project, end of story. |
You're right. Its not up for discussion. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/try...catch around any dependency require should work.
So in a try-catch would hand me this error on a platter. Yet when dealing with N-API when things go wrong your process is quit and you have no recourse. This makes Node unusable as the outer process for any app which must achieve stability if N-API is in play, and you must have a watchdog/orchestrator wrapping the app to ensure such a case is handled. |
I'm going to close this because, with all due respect, I don't think you understand what you're talking about. I'll open a new issue for the tracking the documentation update. |
Version
22.14.0
Platform
Subsystem
NAPI
What steps will reproduce the bug?
Building https://github.com/atom/node-keytar napi using lts-jod makes it incompatible with many other versions of Node, such as the one in Electron 32 (20.18). Building the same package in the same manner using Node 22.13.1 works when running in 20.18.
The keytar.node file built in 22.14.0:
How often does it reproduce? Is there a required condition?
Crashes every time on affected versions.
Building the same package in the same manner using Node 22.13.1 works when running in 20.18.
What is the expected behavior? Why is that the expected behavior?
I expect the NAPI module to work on all versions of Node with support for that NAPI version, and definitely not to break on a minor version bump then start working again after a major.
I would also expect this to be caught by the try-catch the
require
was within.What do you see instead?
Additional information
keytar.zip
94 is built using 22.14.0 and is problematic
93 is built using 22.13.1 and works fine
I don't have the tooling to figure out the differences between them
Downstream issue element-hq/element-desktop#2161
The text was updated successfully, but these errors were encountered: