[TraceQL] Fix subtly incorrect handling of second pass conditions #3734
+33
−133
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What this PR does:
I'm pretty happy about this PR. It started off as a metrics grouping bug, but ended up with deleting very old parquet cruft that's been on our todo list for over a year. 😎
The bug is that conditions put in the second pass could be subjected to existence checks incorrectly. The query
{ } | rate() by(span.foo)
should plot all spans in the "nil" time-series, because the first part{ }
matches all spans, and the second partspan.foo
doesn't exist. However it was returning the dreaded No Data.Adding a condition to the query fixed it.
The source of the bug was the very crufty and very old "requireAtLeastOneMatch" class of optimizations. These optimizations predate the AllConditions, and as we suspected they were redundant and could be deleted. On the second pass we set AllConditions = false so that the second pass is considered truly optional. However these optimizations were forcing it back into an "all-conditions-like" mode and requiring the existent of
by(span.foo)
. Simply deleting these and relying on AllConditions led to the correct behavior.The remaining
batchRequireAtLeastOneMatchOverall
cannot yet be deleted.Here is a snippet from the query_range benchmarks before and after with cases added for this query. Notice that the queries matched 0 spans before, but now they match all spans again. (In fact because all queries have
{ }
they match the same number of spans no matter how they are grouped)Benchmarks for search show some noise, but I don't think this actually changed performance. Because queries
{...} | select(...)
already set AllConditions to false (because of the pipeline). TODO - This can probably be fixed now.BenchmarkBackendBlockTraceQL
Which issue(s) this PR fixes:
Fixes #
Checklist
CHANGELOG.md
updated - the order of entries should be[CHANGE]
,[FEATURE]
,[ENHANCEMENT]
,[BUGFIX]