fix(cli): Sort every Events dataset through a shared resolver

[sentry-junior]

Fixes #1477

Sentry accepts sort on every Events dataset. It only rejects a sort whose column isn't selected: RPC datasets return "orderby must also be in the selected columns or groupby", and the errors events-stats top-events path returns "Cannot sort by a field that is not selected." That 400 is why the CLI decided logs, metrics, and errors dashboard widgets were unsortable, and why it either dropped the sort or warned about it. Without a sort, grouped results come back in no particular order, so --limit returns an arbitrary subset, and offset pagination duplicates and skips rows (getsentry/cli#1519).

This follows the getsentry/cli#1520 approach of making sort work instead of warning, and does it in one shared place: @sentry/toolkit-core/events-sort. resolveEventsSort keeps an explicit sort, otherwise defaults grouped queries to their first aggregate descending, and adds the sort column to field when it's missing. It never adds a non-aggregate column to an aggregate query, because that would change the GROUP BY. The callers:

• sentry explore: sorts every dataset, including logs and metrics. The hand-curated SORTABLE_DATASETS list and the ignore-sort warning are removed, which also takes care of explore: canonical source for sortable dataset list (errors/discover) cli#1523.
• Dashboard widgets: table widgets and grouped (top-events) timeseries now sort for every widget type, not just spans. Grouped timeseries also select their aggregates, which the errors path needs before it accepts the sort.
• MCP search_events: its private augmentFieldsWithSort is replaced by the shared ensureSortInFields. The MCP behavior doesn't change.

I checked against the sentry org: sort=-count() returns rows in descending order on errors, spans, and logs, and on tracemetrics with a matching aggregate. Each dataset 400s only when the sort column isn't selected. On errors, events-stats top events works once the aggregate is added to field.

CLI log list, span list, and trace list keep their fixed sorts, which their fixed field lists already select.

via Junior system actor event.

--

View Junior Session [Sentry]

[vercel]

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

1 Skipped Deployment

Project	Deployment	Actions	Updated
sentry-local	Skipped		Oct 16, 2026 10:38pm UTC

[BYK]

I think what we did was to actually fix the count properly instead of warning and we should fix this everywhere using a centralized mechanism. Research that and redo this PR accordingly.

[BYK]

Perfect. Now let's refactor any other code that might benefit from this new parser.

Also check all Sentry issues in the CLI project for API 400 errors that might get fixed by this and list them here for automatic resolution.

[sentry-junior]

Refactor (90b91d9). These callers now use the shared parser instead of checking for parentheses:

• CLI explore: aggregate checks and the trace-metrics format check. The duplicate isTracemetricsAggregate is gone.
• CLI dashboard widgets: extractFunctionName, the trace-metrics widget check, and the numeric-aggregate field warning. That warning now looks at the first argument, so percentile(span.duration,0.95) no longer triggers it.
• MCP: isAggregateQuery, the search-events and explorer-URL group-by/aggregate splits (now getColumnsAndAggregates), and the Seer sort fallback.

aa0cb43 replaces the frontend regexes with linear scans to fix the CodeQL polynomial-regex alert. A test checks that they give the same answers as the frontend regexes on every field up to 5 characters, including newlines. Tests pass: toolkit-core 73, CLI explore/dashboard 411, MCP 1822.

Sentry cli project, 400s over the last 90 days. I don't see any issue that's safe to auto-resolve:

• The sort-not-selected 400 shows up as two messages: "orderby must also be in the selected columns or groupby" (e.g. --sort -timestamp --field trace) and "Cannot sort by a field that is not selected." (e.g. --sort -count() --field release). This PR fixes both, because the sort column is now always selected.
• Both messages only land in CLI-10 (ApiError: API request failed: 400 Bad Request). That's a catch-all for every explore 400. In 200 recent explore events they made up 10, about 5%. The rest have unrelated causes: unknown functions like p10, string fields passed to min()/p95(), bad date ranges, and project filters. Resolving CLI-10 would just make it come back, so I'd leave it open and watch it after release.
• CLI-2C8, the other big explore 400 group: 0 of 200 sampled events were sort-related.
• The dashboard 400s (CLI-RJ, CLI-1SZ) are widget-save validation errors such as display type not supported for the dataset. This PR doesn't touch those.

If you want these errors to group on their own, the fix would be to fingerprint explore ApiErrors by a normalized api_error.detail. That's a separate change.