| 17:22 | <Abdelrahman Awad> | I looked into this as well and I agree with you that error tracing is mostly useless here. We do two things that’s related to tracing:
First case is mostly not an issue because all of our Span APIs wrap user callbacks and promises, so do similar APIs (Otel), so if anything throws sync or async we set the status in the same call frame the error escapes from. We wouldn't be using the async context for this, which is probably why I didn't look too hard at it or worry about it. If we were to use the async context for setting the span status, then I agree with your team, it would have to be the context closest to the error, otherwise it may point users to the wrong place if they want to fix the error. This might be a case of “technically correct, but practically useless” otherwise. Where it matters for us is everything that has to look the span up, so correlating logs, metrics, and error events to traces/spans, today it is buggy for us and the proposal would fix it. On the two ALS rules, rejections attributing to the resolve/reject context is fine. For uncaught sync errors attributing to the outermost task, the proposal is a non-gain for us since we have no spans to correlate/trace to at that point. This could be that we currently have a server-centric tracing model, we are working on a session model for the client traces but it wouldn’t benefit from the async context either. |