Is your feature request related to a problem? Please describe.
Tag value autocomplete silently discards several kinds of condition instead of applying them, so results include values from spans and traces the user filtered out.
In tempodb/encoding/vparquet{3,4,5}/block_autocomplete.go, these conditions are matched and then dropped with a bare continue, contributing no iterator and no predicate:
createDistinctSpanIterator: IntrinsicSpanID, IntrinsicSpanStartTime — "Metadata conditions not necessary, we don't need to fetch them"createDistinctSpanIterator: IntrinsicStructuralDescendant, IntrinsicStructuralChild, IntrinsicStructuralSibling — already carries a // TODO: Support structural operatorscreateDistinctTraceIterator: IntrinsicTraceID, IntrinsicTraceStartTime — "metadata conditions not necessary, we don't need to fetch them"
The comments are true for the fetch half — we don't need to read those columns to return the metadata — but the conditions are also filters, and dropping them loses the filtering.
Demonstrated against a backend block holding two traces, asking for name values filtered to the first trace:
tr1 := fullyPopulatedTestTrace(common.ID{0x01})
tr2 := fullyPopulatedTestTrace(common.ID{0x02})
tr2.ResourceSpans[0].ScopeSpans[0].Spans[0].Name = "only-in-trace-two"
// FetchTagValues(tag: "name", query: {trace:id="01000000000000000000000000000000"})span names returned: [hello world only-in-trace-two]
only-in-trace-two exists only in the second trace. The trace:id filter was accepted and ignored.
Describe the solution you'd like
Honour these conditions in the autocomplete iterator tree — build a filtering iterator on the corresponding column (TraceID, StartTimeUnixNano, SpanID, span start time) with selectAs left empty so it filters without being collected, the way the other intrinsic cases already do.
Structural operators are a larger piece and could reasonably stay a separate item; the metadata intrinsics look tractable on their own.
Describe alternatives you've considered
Rejecting these conditions with a clear error would at least stop returning wrong answers, but it breaks callers that pass a trace-scoped filter today and would be a regression for anyone relying on the (currently unfiltered) results.
Additional context
Found while fixing #7705. That PR stops the querier panicking when every condition is one of these — because the iterator tree then collapses to an empty join — but deliberately preserves current filtering behaviour. This issue tracks actually applying the filters.
Is your feature request related to a problem? Please describe.
Tag value autocomplete silently discards several kinds of condition instead of applying them, so results include values from spans and traces the user filtered out.
In
tempodb/encoding/vparquet{3,4,5}/block_autocomplete.go, these conditions are matched and then dropped with a barecontinue, contributing no iterator and no predicate:createDistinctSpanIterator:IntrinsicSpanID,IntrinsicSpanStartTime— "Metadata conditions not necessary, we don't need to fetch them"createDistinctSpanIterator:IntrinsicStructuralDescendant,IntrinsicStructuralChild,IntrinsicStructuralSibling— already carries a// TODO: Support structural operatorscreateDistinctTraceIterator:IntrinsicTraceID,IntrinsicTraceStartTime— "metadata conditions not necessary, we don't need to fetch them"The comments are true for the fetch half — we don't need to read those columns to return the metadata — but the conditions are also filters, and dropping them loses the filtering.
Demonstrated against a backend block holding two traces, asking for
namevalues filtered to the first trace:only-in-trace-twoexists only in the second trace. Thetrace:idfilter was accepted and ignored.Describe the solution you'd like
Honour these conditions in the autocomplete iterator tree — build a filtering iterator on the corresponding column (
TraceID,StartTimeUnixNano,SpanID, span start time) withselectAsleft empty so it filters without being collected, the way the other intrinsic cases already do.Structural operators are a larger piece and could reasonably stay a separate item; the metadata intrinsics look tractable on their own.
Describe alternatives you've considered
Rejecting these conditions with a clear error would at least stop returning wrong answers, but it breaks callers that pass a trace-scoped filter today and would be a regression for anyone relying on the (currently unfiltered) results.
Additional context
Found while fixing #7705. That PR stops the querier panicking when every condition is one of these — because the iterator tree then collapses to an empty join — but deliberately preserves current filtering behaviour. This issue tracks actually applying the filters.