webpack: Inevitable unhandled Promise rejection due to failure of prefetch
Bug report
TL; DR: Promise without .catch here.
What is the current behavior?
If you dynamic-import a chunk and that chunk tries to prefetch another chunk, and that prefetch fails for some reason, you get an unhandled Promise rejection reported even if you are doing proper error handling.
If the current behavior is a bug, please provide the steps to reproduce.
Here is a reproduction repo: https://github.com/uhyo/webpack-prefetch-rejection-repro
- Build by
npx webpack. - Open
index.html. - You see an unhandled Promise rejection reported.
The repro includes a custom Webpack plugin (BoomPlugin) that simulates a failure of loading of accompanying resources. Of course, this is just for easily reproducing the issue; the case I actually faced involved mini-css-extract-plugin trying to load a CSS chunk accompanying main chunk.
What is of note is that all import() calls included in source code properly handles Promise rejections. The above image shows how a prefetch failure error is handled by import(...).catch but is still reported as a Promise rejection via another path.
Seems that this unhandled Promise rejection is inevitable; the rejecting Promise is created internally in Webpack runtime and there is no way of preventing that.
What is the expected behavior?
Properly handle the error internally, or provide a way to register a .catch handler to the internal Promise.
Other relevant information: webpack version: 5.51.1 Node.js version: 14.15.0 Operating System: MacoS Mojave 10.14.6 Additional tools:
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 22 (17 by maintainers)
You can solve this on your application side
@vankop Can you look at this?
Sounds reasonable, marked as bug, feel free to send a fix
I will look at this in near future, sorry for delay
@alexander-akait thank you for your investigation!
Our use case is error logging. Failure of CSS chunk loading may happen, and we properly handle the error (we give up loading that resource and show a nice error page to the user). However, our error logging facility (namely Sentry) still logs it as “uncaught runtime error” because of the unhandled Promise rejection reported here, which still happens even though we
.catch()it in our application code. We want to remove this alert since it is not a real problem.We could set up the error logging facility so that we ignore “loading CSS chunk failed” errors, but we consider it as another dirty workaround. Recently unhandled Promise rejections are considered a sort of uncaught runtime errors; for example, Node.js changed the default setting to terminating the process as soon as an unhandled Promise rejection happens. Therefore, we want to remove the root cause of unhandled Promise rejections whenever possible.
I hope this answers your question 🥺