Repository navigation
fix(search-events): Keep explicit timestamp bounds the agent drops - #2139
Draft
sentry-junior[bot] wants to merge 2 commits into
Draft
sentry-junior[bot] wants to merge 2 commits into
sentry-junior[bot] wants to merge 2 commits into
Conversation
When a structured query has timestamp:>= / timestamp:< bounds and the caller also passes period, the embedded agent often moves the bounds into an absolute timeRange and drops them from the query. The explicit period then wins over that range, so the search silently runs over the whole period instead of the requested window. Put any dropped timestamp bounds back on the repaired query. They only narrow the period, so they are safe to send. Grouped and boolean queries are left alone. Co-Authored-By: Sergiy Dybskiy <3760543+sergical@users.noreply.github.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
The grouping guard skipped restoring dropped timestamp bounds whenever a token contained a parenthesis, including parentheses inside a quoted value such as message:"err (timeout)". Strip quoted values before the check so only real grouping skips the restore.
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
search_errorsand the otherrunSearchEventstools can silently run a fixed-window search over the wholeperiod. This happens when the caller sends a structured query withtimestamp:>=/timestamp:<bounds and aperiod.What happens
timeRange({start, end}).period, the handler keepsperiodand discards the agent'stimeRange(search.ts:936-938on main).The only guard on the agent's rewrite is
isSemanticFilterDowngrade, and it only catches filters rewritten into full-text matching. It does not catch filters that were dropped.User feedback reported this more than once: automated callers asked for fixed windows and got rolling-period totals back. In production traces, the agent returned an absolute
timeRangefor the requested window, and the final/events/request still used the caller'sstatsPeriod.Change
After the agent repairs a structured query, any
timestamp:bounds from the caller's query that are missing from the repaired query are appended to it again. The bounds can only narrow the period, so sending them is always safe. Queries withOR/ANDor parentheses are left unchanged, because a bound appended outside its group would change what it means.The regression test sets up this case:
period: "7d", the agent moves the bounds intotimeRangeand drops them from the query, and the request must still carry them. Without the fix, the request query has no bounds.Out of scope: exposing
start/endas tool inputs, which is #1215 / #1228. That work does not cover this path, where aperiodis passed alongside bounds in the query.via @sergical.
--
View Session [Sentry]