Which part? Which one?
Search → Searchable Properties → Events, and the API reference page "List a Tag's Values".
Description
The events searchable-properties page lists device.name as a searchable property: https://docs.sentry.io/concepts/search/searchable-properties/events/#devicename
The "List a Tag's Values" API reference describes GET /api/0/projects/{org}/{project}/tags/{key}/values/ with no caveat about which keys it actually supports: https://docs.sentry.io/api/projects/list-a-tags-values/
However, the project-scoped tags-values endpoint only returns values for tag keys that are promoted to the Snuba tags[...] column at ingest. Context-backed searchable properties such as device.name are stored as Snuba context columns and return 404 from this endpoint, even though the data exists and the property is searchable in Discover/Issue Search. Customers reasonably expect a documented searchable property to work against the documented endpoint and currently get no indication of why the call fails or where to go instead.
Suggested Solution
Two small additions:
- On the API reference page for
/api/0/projects/{org}/{project}/tags/{key}/values/, add a note clarifying that the endpoint only returns values for keys stored as tags. For context-backed searchable properties (e.g. device.name), point readers to the organization-level endpoint: GET /api/0/organizations/{org}/tags/{key}/values/?project={project_id}.
- On the searchable-properties page, optionally annotate context-backed properties so readers know which API endpoint applies to them programmatically.
Which part? Which one?
Search → Searchable Properties → Events, and the API reference page "List a Tag's Values".
Description
The events searchable-properties page lists
device.nameas a searchable property: https://docs.sentry.io/concepts/search/searchable-properties/events/#devicenameThe "List a Tag's Values" API reference describes
GET /api/0/projects/{org}/{project}/tags/{key}/values/with no caveat about which keys it actually supports: https://docs.sentry.io/api/projects/list-a-tags-values/However, the project-scoped tags-values endpoint only returns values for tag keys that are promoted to the Snuba
tags[...]column at ingest. Context-backed searchable properties such asdevice.nameare stored as Snuba context columns and return 404 from this endpoint, even though the data exists and the property is searchable in Discover/Issue Search. Customers reasonably expect a documented searchable property to work against the documented endpoint and currently get no indication of why the call fails or where to go instead.Suggested Solution
Two small additions:
/api/0/projects/{org}/{project}/tags/{key}/values/, add a note clarifying that the endpoint only returns values for keys stored as tags. For context-backed searchable properties (e.g.device.name), point readers to the organization-level endpoint:GET /api/0/organizations/{org}/tags/{key}/values/?project={project_id}.