Repository navigation
perf(cli): Prefetch issue view details for org/numeric IDs - #1931
Merged
Merged
Conversation
When the argument already names the org and numeric issue ID, start the latest-event, replay, and trace requests alongside the issue fetch instead of after it. The trace request also no longer waits on the replay lookup. A merged issue that resolves to a different ID falls back to fetching details for the resolved ID. Fixes CLI-3F5 Co-Authored-By: Miguel Betegon <miguel.betegon@sentry.io>
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
BYK
approved these changes
Nov 4, 2026
BYK
left a comment
BYK
left a comment
Member
There was a problem hiding this comment.
Traces and issues taking this long is not great, we should look into that as a follow up.
7 tasks done
This branch was previously deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
sentry issue view <org>/<numeric-id>ran its requests in a strict chain: issue, then latest event and replays, then trace. The latest event and replay lookups only need the org and ID, which the argument already gives. Now they start alongside the issue fetch, and the trace request starts as soon as the latest event arrives instead of also waiting on replays.On slow connections, each step of the 3-request chain took more than 500ms, which tripped Sentry's Consecutive HTTP detector. Now the issue fetch overlaps the event→trace pair, so the chain is at most 2 steps.
JSON and human output are unchanged. Only the request timing changes.
Before:
After:
(
issue view <org>/<numeric-id> --json --fresh, local run from a low-latency connection. Slower connections save more, about one full issue round-trip.)Other forms (short IDs, selectors, plain numeric IDs, pasted URLs) still wait for the issue. Short IDs, selectors, and plain numeric IDs need the issue response to know the ID or org. Pasted URLs only apply their server once
resolveIssueruns. If the issue resolves to a different ID (a merged issue), the prefetched data is dropped and fetched again for the resolved ID.Fixes CLI-3F5
via bete.
--
View Session [Sentry]