Miss Dada  🏳️‍⚧️

I think my choices here are either to fully wrap promises with my own promise that I can cancel, or else run a fully isolated VM. Really not excited about doing either of those.

I guess there's theoretically option (3): hope that no one actually triggers this. But it's not that difficult to make this kind of mistake...

If I install an "onunhandledrejection" event handler that prints `e.reason.stack`, the "stack" only contains the error message; there's no actual trace. Can I get the trace somehow?

It seems like I can get it if I use Bluebird with "longStackTraces" enabled. Is using Bluebird in a new app a bad idea?

Oh, async/await always use native promises of course. Which means no solution that involves wrapping or any third-party promise library will work. Executing outside the main app's JS context is probably the only way to handle these errors properly. I dislike this.

Conclusion: there seems to be literally no way to execute some JavaScript code without promise rejection errors bubbling all the way up to the top of the execution context (window). And when they get to the top, there seems to be no way to tell where they came from.

Is it possible for you to tag either all user created promises or all app code promises? (By tag I literally mean `promise.came_from_known_place = true`) You can access the original promise from the unhandled rejection event

I can't tag user promises, but I could theoretically tag all of ours. But that would mean permanently excising all async/await from our code. And we'd have to somehow force our special promises into every promise-using library that we use. So maybe possible but very difficult.