Skip to content

fix(search_events): Remove environment from agent validation tool - #1346

Merged
betegon merged 2 commits into
mainfrom
fix/search-events-validation-environment
Sep 28, 2026
Merged

betegon merged 2 commits into
mainfrom
fix/search-events-validation-environment

Conversation

@jamieQ

@jamieQ jamieQ commented Sep 28, 2026 •

Copy link
Copy Markdown
Member

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 environment parameters. 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 environment parameter from the createValidateEventsSearchTool "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 the query parameter 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.

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
jamieQ marked this pull request as ready for review September 28, 2026 12:49
@github-actions github-actions Bot added the risk: medium PR risk score: medium label Sep 28, 2026
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>
@betegon
betegon merged commit c13c685 into main Sep 28, 2026
22 checks passed
@betegon
betegon deleted the fix/search-events-validation-environment branch September 28, 2026 17:05
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

1 active deployment
Actions — d36a0eec Deployed Sep 28, 2026 by betegon via eval #1136
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

risk: medium PR risk score: medium

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants