[sentry-junior]

Closes #1787.

Field completion (explore --field, dashboard widget --query, alert metrics --aggregate, …) reads attribute keys that, until now, only sentry attribute list fetched. So on a fresh login or install it offered nothing.

Warm-up (src/lib/completion-warmup.ts). auth login and cli setup (which cli upgrade runs) now request the spans, logs and tracemetrics keys in parallel, one request per dataset, and abort them all after 1 second so the command never looks stuck. The fetch layer stores the keys as it already does for every response. The warm-up never throws or prompts, and logs failures (404 without the feature, 403, 5xx, offline, timeout) only at debug level.

• Which orgs: the default org, then up to 3 orgs used in the last 7 days. "Used" means a project was resolved or entities were listed in that org (project_cache and completion_cache, not counting the warmed attribute kinds themselves). With no default and no history, it warms the only org if the account has exactly one. Only orgs whose region the active account already has cached qualify, so the warm-up never switches accounts or makes a region lookup it can't abort.
• Login: runs after the result prints and after the org list (which login already fetched in the background), so the account's orgs are known.
• Setup: runs after its output, only when completions are on and a login is stored (an env token, as in CI, never triggers it). It skips any dataset of an org fetched in the last 24 h, so frequent upgrades don't re-download.

Sentry-defined keys first. The endpoint lists the keys an org stores by internal name, one attribute type after another, and appends a few curated aliases and contexts. In a large org, numeric and vendor keys filled the 500-entry cache before span.*. The attribute seed now stores attributeSource.source_type == "sentry" keys first. That covers stored keys that map to a Sentry definition, which the server tags sentry too (translate_internal_to_public_alias). This also helps attribute list.

listTraceItemAttributes takes an optional signal, which the transport already honors during retries.

Open question: in cli setup, the warm-up can be the first API request in the process. So users with NODE_EXTRA_CA_CERTS pointed at SaaS, or with both SENTRY_AUTH_TOKEN and a stored login, now see that one-time advisory notice during upgrades. They already see it on every other networked command. I left it as is rather than adding hooks to suppress those notices. Happy to add them if we want setup to stay fully silent.

Server-side alternative (not used here): GET /organizations/{org}/attribute-mappings/?type=spans&type=logs&type=tracemetrics already returns the static Sentry-defined set without a Snuba query (src/sentry/api/endpoints/organization_attribute_mappings.py). It's EXPERIMENTAL, though. It also includes secondary and deprecated aliases, leaves out virtual contexts, skips the expose checks, and reports units like millisecond as searchType. So the warm-up keeps using the trace-items endpoint, which also returns the org's own keys. Adding a sourceType filter to trace-items would mostly duplicate it, so no getsentry/sentry issue was filed.

via @BYK.

--

View Session in Sentry

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
sentry-local	Skipped		Nov 1, 2026 7:17pm UTC

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit c51cf30. Configure here.}