search_errors / search_logs / search_traces silently ignore an unknown `projectSlugOrId` argument

Offen
  • Stimmt etwas nicht?
#2,231 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
48/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
typescript
Bereich
api

Rechercherichtung

Start by comparing the input schemas of search_issues and search_errors, which name the project argument differently (projectSlugOrId vs projectSlug), and check how the other search tools (search_logs, search_traces, and the rest) declare theirs. Reproduce by calling search_errors with projectSlugOrId and confirming the result link has no project parameter. Done when an unknown project key is rejected or the same argument name works on every search tool, and executedSearch shows the applied project scope. The maintainers still need to choose between the two expected fixes.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

search_issues takes its project as projectSlugOrId, and its own tool description shows that name in its examples and hints. The other search leaves (search_errors, search_logs, search_traces, search_metrics, search_profiles, search_replays) take projectSlug instead. An agent that has just used search_issues often reuses projectSlugOrId on search_errors.

The input schemas don't set additionalProperties: false, so the unknown key is accepted and dropped without any error or warning. The search then runs across the whole organization, even though the caller asked for one project.

Reproduction

Use an organization example-org with projects php-app (ID 123) and go-service:

search_errors(
  organizationSlug="example-org",
  projectSlugOrId="php-app",
  query="errors in the last 24 hours grouped by error type with counts"
)
  • The call succeeds.
  • The result link has no project parameter: ...&query=&field=error.type&field=count%28%29&statsPeriod=24h...
  • The rows include Go error types (*fmt.wrapError, context.deadlineExceededError) from go-service.

The same call with projectSlug="php-app" scopes correctly: the link has project=123, and only php-app errors come back.

executedSearch.query is "" in both responses, because the project filter is a separate request parameter. The response gives the caller no sign that the filter was dropped.

Expected

Either of these would prevent the silent cross-project result:

  1. Reject unknown arguments (strict input schemas, or a validation error that names the unknown key and the expected one).
  2. Accept the same project argument name on every search tool (for example, accept projectSlugOrId as an alias of projectSlug, or the other way round).

It would also help to show the applied project scope in executedSearch, so callers can check it.

Environment

Remote MCP at https://mcp.sentry.dev/mcp, called through our MCP gateway, which forwards tool arguments unchanged.

Vorherrschende Sprache
TypeScript
Sterne
961
Forks
179
Ø Merge
15 Std. 33 Min.
Gemergte PRs (30 T.)
476

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus getsentry/toolkit

Alle Issues in getsentry/toolkit

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.