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

未关闭
  • 哪里不对？
#2,231 2 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
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 分钟
30 天内合并 PR
476

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

getsentry/toolkit 的其他 Issue

查看 getsentry/toolkit 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。