Miss Dada  🏳️‍⚧️

As expected, I'm hitting some nasty problems where user code in the concurrency course can crash the app. E.g., if you write code that leaks a promise with a chaining cycle, then it will result in an unhandled rejection, which makes us show the "oops" page.

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.