2026-09-03
[15:36:39.0186] <Steve Hicks>
I've been looking into uncaught error / unhandled rejection attribution (see AI-generated report/slop at https://gist.github.com/shicks/7c53b5ebfcc6d4ae970c38383ef72ed4).  The current precedent from ALS is to have uncaught errors attribute to the outermost task that failed to catch them (i.e. the registration context for a `setTimeout`, or in most cases no context), and for unhandled rejections to attribute to the context when the Promise ctor's resolve/reject was called (which in practice works out to be the same as the context surrounding the `then` call).

Is this the behavior we're most likely to go with?  A quick chat with our tracing team suggests that they're worried about losing the context from closer to where the error was actually thrown.  I could imagine trying to set things up so that e.g. catch blocks restore the context from the thrown error, possibly similar with promise.catch (etc), which would be a lot more useful for tracing.  Or maybe there's other ways to get it - but going with the ALS precedent basically makes error tracing useless.  I'm really curious what Abdelrahman Awad's experience with this precedent is.