#Errors in async spans
1 messages ยท Page 1 of 1 (latest)
I think we can split this into 2 parts
-
What function did this span originate from? (regardless of whether it's sync or async). That is the relationship I care most about, before even caring about the laziness/async aspect. If there's one function I'm interested in in the screenshot, it's
withExec. -
Is this a synchronous or asynchronous span? And if async: what other calls triggered the "unlazying"? That can be useful in some cases as I dig further. But nowhere near as important as the first question.
In other words, if I have to choose between:
- correctly showing the function call that started the failed span, but not knowing what other function unlazied it, or even whether it was unlazied or not;
and 2) correctly showing that the failed span was async, and which call unlazied it - but not showing me what call actually started it.
I always choose 1.
Obviously if we find a way to perfectly show all the information all the time, and the UI for it is nice, that's even better ๐
I think we have all the info necessary to show all that ๐
we know when something is async / has future "effects" (calls like withExec return llb.digests=[list of digests that might show up in the future as a span], and how to identify them when they come in (span has vertex=effect digest), and know where they were unlazied (parent of effect span)
And in fact point 2) (the luxury/nice-to-have information) gets even more rich and complex, if you consider that there's the function call that triggered the unlazying; and then there are the multiple function calls that are downstream from the result of the error (there could be 10 calls to file(), running in parallel, waiting for that one exec to complete. Sure one of them was called 2ms sooner and technically that's the one that triggered the unlazying, but in practice all 10 are equally important to show, unless you're specifically debugging race conditions in the engine)