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

オープン
  • 何か問題がありますか？
#2,231 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
api

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
TypeScript
スター
961
フォーク
179
平均マージ
15時間 33分
マージ済み PR（30日）
476

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

getsentry/toolkit のほかの issue

getsentry/toolkit の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。