Repository navigation
explore: canonical source for sortable dataset list (errors/discover) #1584
Description
In getsentry/cli#1520 we hard-coded SORTABLE_DATASETS = new Set(["spans", "errors", "discover"]) based on live-org probe + existing spans guard.
We should have a canonical, machine-readable source (or at least a documented contract) rather than a static list that can drift. Possible homes:
- @sentry/api SDK
- Sentry server (events endpoint capability)
- Snuba schema / Discover docs
This would let the CLI (and other clients) query "which datasets accept sort on grouped aggregates?" instead of maintaining a hand-curated set.
cc @BYK
Activity
explore: document sortable-dataset contract, drop dead discover entry (…
fix(cli): Sort every Events dataset through a shared resolver (#1521)
linear-code commentedon Oct 22, 2026
MCP-1107
sentry-junior commentedon Oct 22, 2026
Closing this as no longer valid. #1521 removed the hard-coded
SORTABLE_DATASETSlist, so there's nothing left to replace with a canonical source.It turned out there isn't a per-dataset sort capability to look up: every Events dataset (errors, spans, logs, tracemetrics, and so on) accepts
sort. The one rule Sentry enforces is that the sort column has to be selected. RPC datasets return "orderby must also be in the selected columns or groupby", and errorsevents-statsreturns "Cannot sort by a field that is not selected." That 400 is why the original list looked like dataset support.That rule now lives in one shared place,
packages/toolkit-core/src/events-sort.ts(resolveEventsSort/ensureSortInFields). The CLI'ssentry explore, dashboard widgets, and MCPsearch_eventsall use it. It adds the sort column tofieldwhen that's safe, and defaults grouped queries to their first aggregate descending. A capability endpoint in Sentry or@sentry/apiwould have nothing to report beyond that rule, so I don't think it's worth pursuing.If a dataset that really doesn't support sort shows up later, we can reopen this and use that as the starting point.