[cursor]

Summary

Three independent bug fixes discovered via code analysis of the codebase. Each fix is a separate commit.

---

1. fix(sourcemap): Guard JSON.parse in injectDebugId against malformed .map files

Root cause: JSON.parse(mapContent) in src/lib/sourcemap/debug-id.ts:155 was the only unguarded JSON.parse in the codebase. Malformed .map files crash the sourcemap inject command with an opaque SyntaxError.

Reproduction: Run sentry sourcemap inject on a directory containing a .js file whose companion .map has invalid JSON.

Fix: Wrapped in try/catch that throws a ValidationError with the file path, matching the pattern used in inline-sourcemap.ts and throughout the rest of the codebase.

---

2. fix(logs): Cap per_page at API_MAX_PER_PAGE in log list APIs

Root cause: Both listLogs() and listTraceLogs() in src/lib/api/logs.ts passed the user's --limit directly as per_page. When limit > 100, the API silently caps at 100, but the caller's hasMore check (logs.length >= flags.limit) evaluates to false, hiding remaining data.

Reproduction: Run sentry log list --limit 200 on a project with >100 logs. Only ~100 are returned and the hint says there are no more.

Fix: Cap both calls with Math.min(limit, API_MAX_PER_PAGE), matching the project convention documented in AGENTS.md: "Never pass a per_page value larger than API_MAX_PER_PAGE to the API."

---

3. fix(dashboard): Drop nextCursor on pagination overshoot in revisions list

Root cause: In src/commands/dashboard/revisions.ts, when multi-page fetching accumulates more results than flags.limit, the excess is trimmed but the API cursor from the last fetched page is still stored. On -c next, those trimmed items are silently skipped.

Reproduction: Run sentry dashboard revisions <id> --limit N where N causes multi-page overshoot (e.g., --limit 150 with 100 items per page, where 2 pages return 160 items total).

Fix: Drop nextCursor when results overshoot the limit, matching the autoPaginate() pattern in infrastructure.ts (lines 419-420).

  

[github-actions]

PR Preview Action v1.8.1
🚀 View preview at https://cli.sentry.dev/_preview/pr-1118/
Built to branch gh-pages at 2026-06-22 12:21 UTC. Preview will be ready when the GitHub Pages deployment is complete.

[github-actions]

Codecov Results 📊

❌ Patch coverage is 71.43%. Project has 5049 uncovered lines.
✅ Project coverage is 81.24%. Comparing base (base) to head (head).

Files with missing lines (1)

File	Patch %	Lines
src/lib/sourcemap/debug-id.ts	50.00%	⚠️ 2 Missing

Coverage diff

@@            Coverage Diff             @@
##          main       #PR       +/-##
==========================================
+ Coverage    81.24%    81.24%        —%
==========================================
  Files          388       388         —
  Lines        26910     26914        +4
  Branches     17481     17483        +2
==========================================
+ Hits         21861     21865        +4
- Misses        5049      5049         —
- Partials      1822      1822         —

---

Generated by Codecov Action

[sentry-warden]

hasMore = true when overshot but no cursor stored causes -c next to throw a ValidationError

When the multi-page fetch overshoots flags.limit, hasMore is set to true and the paginationHint prints a -c next hint, but cursorToStore is undefined, so advancePaginationState stores no next entry in the stack. Running --cursor next then hits state.index + 1 >= state.stack.length in resolveCursor and throws "No next page saved for this query" — the opposite of what hasMore: true implies.

Evidence

• overshot = true → cursorToStore = undefined (line 208); hasMore = true (line 203).
• advancePaginationState(..., direction='first', undefined) stores stack = [''] with no next entry (pagination.ts:265: nextCursor ? ['', nextCursor] : ['']).
• outputData.hasMore = true causes paginationHint to emit the -c next hint (revisions.ts line 229).
• resolveCursor(..., 'next') in pagination.ts:198 checks state.index + 1 >= state.stack.length → 1 >= 1 → throws ValidationError('No next page saved for this query.').
• autoPaginate() (infrastructure.ts line 419) never exposes hasMore to callers, so the cited comparison does not apply here where hasMore is surfaced directly in CLI output.

_{Identified by Warden find-bugs · LHQ-E68}

[sentry-junior]

Closing as part of archiving getsentry/cli; the CLI now lives in getsentry/toolkit. The dashboard revisions cursor fix is ported in getsentry/toolkit#1608 (remaining-budget pages, cursor dropped on overshoot), and the sourcemap JSON guard in getsentry/toolkit#1609. The log per_page cap isn't needed anymore because log listing goes through paginate().