Repository navigation
fix(search_events): Remove environment from agent validation tool - #1346
Merged
Merged
Conversation
Production traces show the query agent repeatedly inventing environment arguments for validateSearch, exhausting its step budget before returning a search. Keep environment filters in the candidate query while preserving final search environment handling. Co-Authored-By: GPT-6 <noreply@openai.com>
jamieQ
marked this pull request as ready for review
September 28, 2026 12:49
Keep non-replay environment filters in the query and avoid unsolicited filters when grounding lists a single environment. Add HTTP contract coverage and grounded model regressions for intermediate calls and final output. Co-Authored-By: GPT-6 <noreply@openai.com>
BYK
pushed a commit
that referenced
this pull request
Sep 30, 2026
…1346) The env-token-ignored hint claimed the user set a `SENTRY_AUTH_TOKEN` env var even when the token actually came from a `[auth] token` in `.sentryclirc` (the shim copies it into `SENTRY_AUTH_TOKEN` at boot). The shim now records the injecting `.sentryclirc` path and the hint names it instead, so the source is accurate. Scoped to the incorrect-source bug from #1345. The larger behavior proposal in the issue (trust org/host-embedded tokens, only fall back to the stored DB token when the other fails/can't be trusted) is a separate design change and isn't included here. ## Testing `pnpm exec vitest run test/lib/auth-hint.test.ts test/lib/sentryclirc.test.ts` (39 passed), plus `pnpm run typecheck` and `pnpm run lint` clean. Closes #1345 <!-- ## Plan Root cause: applySentryCliRcEnvShim in src/lib/sentryclirc.ts maps a .sentryclirc [auth] token into env.SENTRY_AUTH_TOKEN. Later, maybeWarnEnvTokenIgnored in src/lib/auth-hint.ts reports "Detected SENTRY_AUTH_TOKEN env var" using getActiveEnvVarName(), which cannot tell an rc-injected token from a real env var. The user sees a wrong source. Changes: - src/lib/sentryclirc.ts: add module-local rcInjectedTokenSource, set it to config.sources.token when the shim injects the token, expose getRcInjectedTokenSource(), and reset it in clearSentryCliRcCache(). - src/lib/auth-hint.ts: add describeIgnoredTokenSource() naming the .sentryclirc file when rc-injected, else the env-var name. - tests for both the shim provenance and the hint wording. Out of scope: token trust/precedence changes (issue items 1 and 2). --> --------- Co-authored-by: jared-outpost[bot] <jared-outpost[bot]@users.noreply.github.com>
mr-danya
pushed a commit
to mr-danya/sentry-mcp
that referenced
this pull request
Oct 6, 2026
…etsentry#1346) The env-token-ignored hint claimed the user set a `SENTRY_AUTH_TOKEN` env var even when the token actually came from a `[auth] token` in `.sentryclirc` (the shim copies it into `SENTRY_AUTH_TOKEN` at boot). The shim now records the injecting `.sentryclirc` path and the hint names it instead, so the source is accurate. Scoped to the incorrect-source bug from getsentry#1345. The larger behavior proposal in the issue (trust org/host-embedded tokens, only fall back to the stored DB token when the other fails/can't be trusted) is a separate design change and isn't included here. ## Testing `pnpm exec vitest run test/lib/auth-hint.test.ts test/lib/sentryclirc.test.ts` (39 passed), plus `pnpm run typecheck` and `pnpm run lint` clean. Closes getsentry#1345 <!-- ## Plan Root cause: applySentryCliRcEnvShim in src/lib/sentryclirc.ts maps a .sentryclirc [auth] token into env.SENTRY_AUTH_TOKEN. Later, maybeWarnEnvTokenIgnored in src/lib/auth-hint.ts reports "Detected SENTRY_AUTH_TOKEN env var" using getActiveEnvVarName(), which cannot tell an rc-injected token from a real env var. The user sees a wrong source. Changes: - src/lib/sentryclirc.ts: add module-local rcInjectedTokenSource, set it to config.sources.token when the shim injects the token, expose getRcInjectedTokenSource(), and reset it in clearSentryCliRcCache(). - src/lib/auth-hint.ts: add describeIgnoredTokenSource() naming the .sentryclirc file when rc-injected, else the env-var name. - tests for both the shim provenance and the hint wording. Out of scope: token trust/precedence changes (issue items 1 and 2). --> --------- Co-authored-by: jared-outpost[bot] <jared-outpost[bot]@users.noreply.github.com>
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.
Translating a user query into a valid search event API call seems to often fail. One reason that seems fairly common is that models end up hallucinating invalid
environmentparameters. E.g. see this representative trace in which a model repeatedly tries to use":/"as an environment value. Sometimes the models correct these mistakes before the retry budget is spent, but other times this just results in a terminal failure.Try to fix this by removing the
environmentparameter from thecreateValidateEventsSearchTool"schema" so that models are (hopefully) less likely to fill that field with garbage values. AFAICT the field is unnecessary for internal validation, since the env should be passed via thequeryparameter for most datasets. Replays is apparently an exception, but I don't believe it depends on this validation logic currently so should be unaffected. Local testing suggested this improved the model behavior in some cases that were modeled after production failures.