ref(profiling): document chunks project param as ID-or-slug, not int#118051
Merged
Conversation
The profiling chunks endpoint declared its `project` query param as
`type=int` ("The ID of the project"), while the sibling flamegraph endpoint —
same base class, same `get_snuba_params` parsing — documents the same param via
OrganizationParams.PROJECT as accepting IDs *or slugs*. The runtime resolves
slugs to numeric ids in get_snuba_params before anything reaches Snuba, so
`type=int` was an under-specification.
Effect downstream: the generated @sentry/api SDK typed chunks' `project` as a
scalar `number`, forcing consumers (e.g. sentry-mcp) to coerce with Number() —
which turns a project slug into NaN and breaks slug-based lookups.
Change the param to `type=str` ("ID or slug"), keeping the 'exactly one project'
semantics enforced in the handler. Pure OpenAPI-declaration change; no runtime
behavior change.
Verified: spectacular --validate --fail-on-warn clean; generated param is now string.
github-actions
Bot
added
the
Scope: Backend
gricha
approved these changes
Jun 18, 2026
betegon
added a commit
to getsentry/sentry-mcp
that referenced
this pull request
Jun 19, 2026
getsentry/sentry#118051 fixed the profiling-chunks `project` param to be documented as an ID-or-slug (string) instead of a scalar int, so @sentry/api 0.232.0 now types getProfileChunk's `project` as string. Replace the temporary `projectId as number` cast with `String(projectId)` — numeric ids serialize as-is, slugs are preserved, no cast. The slug guard test still passes. Verified: tsc clean (no other breakage from 0.228->0.232); full mcp-core suite unchanged (1162 pass; the 2 fails remain the pre-existing autofix run_id/sentry_run_id tests, tracked separately).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The profiling chunks endpoint (
GET /organizations/{org}/profiling/chunks/) declares itsprojectquery param astype=int("The ID of the project"), while the sibling flamegraph endpoint — same base class (OrganizationProfilingBaseEndpoint), sameget_snuba_paramsparsing — documents the sameprojectparam viaOrganizationParams.PROJECTas accepting IDs or slugs.The runtime already resolves slugs → numeric project ids in
get_snuba_params(Snuba only ever receives numeric ids), sotype=intis an under-specification, not a real numeric-only contract.This changes it to
type=str("ID or slug"), keeping the existing "exactly one project must be specified" semantics (still enforced in the handler).Why it matters (downstream)
The generated
@sentry/apiSDK typed chunks'projectas a scalarnumber. Consumers (e.g. sentry-mcp) therefore coerced input withNumber(projectId)— which turns a project slug intoNaNand breaks slug-based profile-chunk lookups. With this change the SDK regeneratesprojectas a string, so consumers can forward an ID or slug directly (no coercion, no cast).Scope
OpenApiParameter. No runtime behavior change — the handler andget_snuba_paramsare untouched.get_snuba_params; Snuba receives numeric ids regardless.Verification
sentry django spectacular --validate --fail-on-warnis clean, and the generatedprojectparam schema is now{"type": "string"}(wasinteger), with the description updated to "ID or slug". The frontend calls this endpoint via PageFilters (numeric project ids), which remain valid.cc @getsentry/profiling (owners) — flagging in case the scalar
intwas intentional; if chunks is meant to be numeric-only, happy to instead align the consumer side, but the shared runtime + the flamegraph sibling suggest IDs-or-slugs is correct.