fix(issue): warn that list counts are not scoped to the release: filter

[jared-outpost]

What

sentry issue list --query 'release:"X"' correctly restricts which issue
groups are returned, but the count/userCount it displays are period-wide
totals across every release, not the counts matching the release filter.
Nothing in the output signals this, so a release-scoped triage silently
over-reports, and --sort freq/--sort user rank by the same unscoped counts.

Root cause

The Sentry issues-list endpoint's per-group seen-stats (count, userCount,
firstSeen, lastSeen) honor the statsPeriod but are not scoped to
arbitrary query filters like release:. The events endpoint returns correctly
scoped values, but the issues endpoint's stats are not filter-aware. The factor
is not constant (it depends on how a group is distributed across releases), so
the numbers can't be corrected after the fact.

Fix

Rather than silently over-report, mark the counts as unscoped — the minimal,
defensible path the issue itself proposes under "Expected":

• New unscopedCountFilterKeys(query) in search-query.ts parses the query AST
  (recursing into paren groups) and returns the count-unscoped filter keys
  present. Currently that set is { release }; it's trivial to extend.
• issue list surfaces a warning when such a filter is active and the counts
  are shown:
  • Human — a footer note explaining EVENTS/USERS are period-wide totals
    not scoped to the release: filter (and, for --sort freq/user, that the
    ordering follows the unscoped counts), pointing at the events endpoint.
  • JSON — a machine-readable _countScope field in the envelope
    ({ _type, filters, fields, message }), following the existing
    _searchSyntax injection precedent.

No behavior change when the query has no count-unscoped filter, and the note is
suppressed in JSON when --fields collapses the count fields away.

Tests

• test/lib/search-query.test.ts — unscopedCountFilterKeys across plain,
  in-list, paren-group, case-insensitive, dedup, free-text, and unparseable
  inputs.
• test/commands/issue/list.test.ts — JSON envelope gains/omits _countScope;
  human output appends/omits the note (incl. the --sort freq clause).

pnpm vitest run test/lib/search-query.test.ts test/commands/issue/list.test.ts
→ 138 passed. tsc --noEmit clean.

Closes #1518

[vercel]

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

Project	Deployment	Actions	Updated
cli	Ready	Preview	Sep 3, 2026 2:31pm UTC

[jared-outpost]

ci was red on `check:errors` — the new `catch {}` in `unscopedCountFilterKeys` tripped the silent-catch ratchet (1 → 2 in `search-query.ts`). Fixed by logging the parse failure at `log.debug` instead of swallowing it; an unparseable query has no keys to detect and the API returns a proper 400 anyway. The Unit Tests / CI Status failures were the downstream cascade from that same lint job (the issue list tests themselves passed, 59/59).

[jared-outpost]

ci is green except `warden: security-review`, which failed with an infrastructure error, not a code finding:

Skill execution failed — Error: Provider unavailable: all 3 chunks failed to analyze. Warden stopped early.

The companion `warden` check ran the same `security-review` skill on this commit and reported 0 findings ("No issues found. | security-review | 0"). Lint & Typecheck, Unit Tests, and CI Status all pass on 50d463c.

I do not have permission to re-request the warden check (it is a GitHub App check, not a rerunnable Actions workflow — `rerequest` returns 403). A maintainer can re-run it from the Checks tab, or it will re-run on the next push. No code change is warranted.

[BYK]

Jared, why are we not fixing the counts instead??