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

Ouverte
  • Quelque chose ne va pas ?
#2,231 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
48/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
typescript
Domaine
api

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
TypeScript
Étoiles
961
Forks
179
Merge moyen
15 h 33 min
PR mergées (30 j)
476

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de getsentry/toolkit

Toutes les issues de getsentry/toolkit

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.