Skip to content

fix(eap-items): Only use indexed_name for ranges after it was populated - #8496

Merged
phacops merged 10 commits into
masterfrom
feat/indexed-name-time-based
Sep 28, 2026
Merged

phacops merged 10 commits into
masterfrom
feat/indexed-name-time-based

Conversation

@phacops

@phacops phacops commented Sep 25, 2026 •

Copy link
Copy Markdown
Contributor

The indexed_name rewrite now only applies to requests whose time range starts after indexed_name was fully populated. Orgs in eap_items_use_indexed_name_organization_ids still read the bloom-filter-indexed column for equality and IN filters on sentry.op (spans) and sentry.metric_name (metrics). Now that also requires the request's start_timestamp to be at or after the new eap_items_indexed_name_start_timestamp option. Older ranges keep the attributes_string lookup.

Without the cutoff, an enabled org querying older data silently loses rows. Rows written before the column was populated have an empty indexed_name, and until #8488 metrics filled it from the wrong attribute.

The schema default is 2026-09-23 00:00 UTC: the first midnight after #8488 merged (2026-09-22 14:43 UTC) plus an hour of padding. That is not a verified deploy time across regions. If any region deployed #8488 later, raise the option to the midnight after that deploy before enabling orgs there. The code passes 0 as the get_option fallback. That value is only used if the option can't be read, and the cutoff is only read after the org check passes.

The org list's schema description now also names the correct metric attribute, sentry.metric_name.

Requests whose start_timestamp is at or after eap_items_indexed_name_start_timestamp (default 2026-09-25 00:00 UTC) now read the bloom-filter-indexed indexed_name column for sentry.op / sentry.metric_name equality and IN filters, regardless of the per-org allowlist. Older ranges still require the org to be listed, since rows written before the column was fully populated would otherwise be dropped.
@phacops
phacops marked this pull request as ready for review September 25, 2026 22:30
@phacops
phacops requested review from a team as code owners September 25, 2026 22:30
The indexed_name rewrite now requires both the org allowlist and a request range starting at or after eap_items_indexed_name_start_timestamp. The cutoff default lives only in the schema; the code falls back to disabling the rewrite if the option can't be read.
@phacops phacops changed the title feat(eap-items): Use indexed_name for all orgs on recent time ranges feat(eap-items): Gate indexed_name rewrite on a populated-since cutoff Sep 25, 2026

@pbhandari pbhandari left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with this as is; but ideally we accept a datetime as a string so the options-automator config is readable without us needing to parse the timestamp into a datetime.

@phacops phacops changed the title feat(eap-items): Gate indexed_name rewrite on a populated-since cutoff fix(eap-items): Only use indexed_name for ranges after it was populated Sep 25, 2026
Without a fallback, get_option relies on the schema default and raises on read errors instead of silently using a value from code. The indexed_name cutoff now reads the option this way, so its only default is the schema's.
…name cutoff

Reverts the optional get_option fallback. The cutoff read falls back to 0 if the option can't be read; the schema default still applies normally.
Comment thread snuba/web/rpc/common/common.py Outdated
Falling back to 0 made every time range eligible for the indexed_name rewrite if the option read failed, which could silently drop rows written before indexed_name was populated. Fall back to a cutoff no request can reach instead.
@phacops
phacops enabled auto-merge (squash) September 28, 2026 21:31
@phacops
phacops merged commit 35ba174 into master Sep 28, 2026
70 checks passed
@phacops
phacops deleted the feat/indexed-name-time-based branch September 28, 2026 21:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants