[sentry-junior]

search_traces runs a natural-language request verbatim when it also contains a filter token. Sentry then searches the prose as literal text and returns nothing, with no warning. User feedback MCP-SERVER-GQ5 and MCP-SERVER-GMW both report this.

In production (MCP server 0.42.0), one call sent query = "production transactions (is_transaction:true), show timestamp, transaction, span.op, release". The embedded agent's validateSearch call built sentry.environment:production AND is_transaction:true and got valid: true. Even so, executedSearch.query was the original sentence, and the search returned nothing.

Cause

search_traces always sends dataset: "spans". So any query that passes looksLikeSentrySearchSyntax takes the trusted structured-trace path (shouldTrustStructuredTraceSearch). On that path, choosePreservingRepairedQuery keeps the agent's rewrite only when every original token appears in it. That includes prose words like show, grouped, and release,. A correct translation never has those words, so the original sentence runs instead.

Change

A query with filters plus two or more unquoted free-text words (mixesSearchSyntaxWithProse) is now handled as natural language, so the agent's translation runs. The existing isSemanticFilterDowngrade guard still rejects rewrites that turn a filter into full-text matching, and explicit fields, sort, and period are still kept. These queries are still trusted as typed:

• filter-only queries
• quoted phrases
• a single free-text term next to a filter, such as span.op:db SELECT

Open question: a query with filters plus several literal free-text words now goes through the agent instead of running as typed. Two or more words matches the existing natural-language heuristic in formatUntranslatedQueryNote. Seer still skips queries that contain a filter token, so mixed queries go to the embedded agent.

via Sentry.

--

View Session [Sentry]

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
sentry-local	Skipped		Nov 14, 2026 2:15am UTC

[sentry-junior]

Another report of this pattern, this time from search_logs (MCP user feedback, server 0.42.0). Reports: 3 (GQ5, GMW, and this one).

The caller sent a sentence with filter tokens in it, along with explicit fields and sort:

• query: Count logs matching message:"*<a>*" or message:"*<b>*" from <ISO start> to <ISO end>, grouped by message
• fields ["message","count()"], sort -count(), period 24h

The query has filter tokens, dataset is logs (a trace-item dataset), and explicit fields and sort were passed, so canRunWithoutAgent was true (search.ts:784-785 on main). The sentence ran verbatim with no agent step. Sentry's validate endpoint rejected it with:

INVALID query — Unknown attribute
  INVALID <date>T20 — Unknown attribute   (×2, one per ISO timestamp)

The HH:MM:SS colons in the ISO timestamps turn the date part into an attribute key.

On this branch, I ran mixesSearchSyntaxWithProse on the exact production query with dataset logs, and it returns true. shouldTrustStructuredTraceSearch, and with it canRunWithoutAgent, is then false, so the agent translates the request. So this PR covers the search_logs case too; I didn't open a separate fix.

The same report also hit a different bug: open-ended "since X" ranges. That one is tracked separately in #2272.

[sentry-junior]

Another report of this pattern, from search_traces again (MCP user feedback MCP-SERVER-GQC, server 0.42.0). Reports: 4 (GQ5, GMW, GQA, and this one).

The user's agent said search_traces "passed a mixed explicit-filter and natural-language query through literally, yielding zero time-series results", and that a rerun with pure Sentry syntax and explicit fields returned data.

What I could check in the traces:

• The failing mixed-prose search_traces call was not sampled, so I can't show its exact query or response.
• The retries are sampled and are pure syntax, e.g. trace 19ce72ee5d69460b8fc2343f96330629: query = "environment:production span.op:http.server timestamp:>=… timestamp:<…", fields = ["http.response.status_code","count()","min(timestamp)","max(timestamp)"], sort -count(). executedSearch.query equals the input and the call returned rows. That fits the workaround the user described.

So this report matches the pattern by its description, but the trace evidence only covers the workaround. Confidence: medium.