TraceQL: How to check whether every descendant has a specific attribute?

[vprithvi]

I have a trace like the following, where every span in the A, C, D, F path has error=true.
Is there a way to retrieve such traces using traceQL?

Using the descendent operator today also matches traces like the following, which I am not interested in.

[mdisibio]

Hi this is a really interesting challenge. I don't have an answer yet, but leaving some thoughts that might be helpful.

(1) Find spans in the chain
We can find spans from each direction like this:
{a && status=error} >> { } and {f && status=error} << { } This finds all descendants of a, and all ancestors of f. What we need is a way to intersect them, but I'm not sure that's possible. The current operation && is a merge/union, and not an intersection.

(2) Determine if all spans are errored
We could group the spans by status, this would create 3 groups: unset, success, and error. Checking unset and success for a count of 0 would mean that all remaining spans are errored.

[joe-elliott]

we call "not structural" operators experimental b/c they can return false positives, but they can still be quite useful.

this might be close to what you want:

{ status = ok } !>> { f }

[vprithvi]

Thank you both - to share more context, I'm trying to classify root endpoints/operations based on whether errors from interior services bubble up all the way to the root service. When errors bubble all the way up, one can conclude that some service(s) in the call path do not/cannot gracefully degrade.

As such, I do not know which interior service the error originates from (for e.g., it may not be f and can be any arbitrary descendant).

@joe-elliott - While the not structural operator is interesting, it doesn't help me here :(
@mdisibio - This is interesting, I wonder whether an approach of (2) followed by (1) would help. For e.g. if we build traces utilizing only error spans, and then querying for the descendants. Because of the initial filtering, the traces would be incomplete, but only contain error paths, and any contiguous path from the root should show the origination point of the error

[joe-elliott]

i think this?

{ status = ok } !>> ({ <some root conditions> && status = error } >> { status = error })