Skip to content

Resolve merge conflict in query fuzz test helpers - #7849

Closed
CharlieTLe with Copilot wants to merge 2 commits into
masterfrom
copilot/resolve-merge-conflicts-7551
Closed

CharlieTLe with Copilot wants to merge 2 commits into
masterfrom
copilot/resolve-merge-conflicts-7551

Conversation

Copilot AI commented Sep 18, 2026

Copy link
Copy Markdown
Contributor

What this PR does:

Resolves the conflict in integration/query_fuzz_test.go by carrying forward both sides of the change instead of dropping either the PR-specific fuzz exclusion or the newer master-side fuzz helper logic.

  • Conflict resolution

    • preserves the PR’s hasOrVectorFallback() guard and its focused unit test
    • keeps master’s newer fuzz infrastructure, including deterministic FUZZ_SEED handling and duplicate-series error canonicalization
  • Resulting behavior

    • isValidQuery() still rejects the known or vector(...) false-positive shape
    • the fuzz suite also retains the newer reproducibility and error-equivalence helpers introduced on master
  • Merged shape

    if hasOrVectorFallback(generatedQuery) {
    	return false
    }

Checklist

  • Tests updated
  • Documentation added
  • CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]
  • docs/configuration/v1-guarantees.md updated if this PR introduces experimental flags

sandy2008 and others added 2 commits May 22, 2026 19:07
TestVerticalShardingFuzz flakes when promqlsmith emits an expression
containing `<lhs> or vector(<rhs>)` against block data with partial
time coverage on the LHS: Cortex's vertically-sharded query path and
the unsharded reference engine disagree on which timestamps trigger
the `vector(...)` fallback, because each shard decides locally
whether the LHS is empty at a given step while the unsharded path
sees the union. Both answers are individually correct under their
own model, but the final results diverge on a handful of points.
Same analyser-side family as the known `absent` / `absent_over_time`
/ `scalar` cases (#5203, #5204, #5205): the Thanos PromQL analyser
does not classify `or vector(...)` as non-shardable. Full empirical
census in #7547.

Add hasOrVectorFallback(parser.Expr), an AST walker that uses
parser.Inspect to detect any *parser.BinaryExpr with Op == parser.LOR
whose RHS is a *parser.Call to the `vector` function. Call it from
isValidQuery alongside the existing `limitk` / `limit_ratio` / `--`
filters so every fuzz caller (TestVerticalShardingFuzz plus the
seven other fuzz tests that go through runQueryFuzzTestCases) skips
the offending shape.

An earlier draft used `strings.Contains(queryStr, "vector(")`. Round-2
review flagged that as too broad: a substring scan fires on bare
`vector(0)`, `sum(vector(1))`, `vector(1) + on() vector(2)`, and even
on incidental `vector(` text inside label literals — none of which
diverge between the sharded and unsharded engines. The AST predicate
matches only `<lhs> or vector(<rhs>)`, leaving the rest of the random
surface intact.

Add TestHasOrVectorFallback with six subtests pinning the predicate:
`up` (no), `vector(1)` (no — bare call is fine), `up or up` (no — `or`
without `vector`), `up or vector(1)` (yes), a deep-LHS positive
(`(sum(rate(up[1m])) == bool 0) or vector(0)`), and a simplified form
of the actual failing query from #7547. All six pass locally.

This is a test-side dodge, not a sharding-engine fix. The proper
upstream change — teaching the Thanos analyser to recognise
`or vector(...)` as non-shardable, mirroring the existing
`absent` / `scalar` exclusions — is tracked separately.

Trade-off: isValidQuery is global to all fuzz callers, so random
fuzz coverage of `or vector(...)` is dropped everywhere, not just
in TestVerticalShardingFuzz. Accepted for the reasons in #7547:
the empirical signal points at the sharded vs unsharded path as
the only current divergence context, and the filter becomes moot
the moment the upstream analyser is fixed.

Fixes #7547

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Sandy Chen <Yuxuan.Chen@morganstanley.com>
…ge-conflicts-7551

# Conflicts:
#	integration/query_fuzz_test.go

Co-authored-by: CharlieTLe <3375195+CharlieTLe@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants