fix(resolution): correct hint for bare suffix in org/suffix issue ID - #1296
Conversation
|
Codecov Results 📊✅ Patch coverage is 100.00%. Project has 5466 uncovered lines. Coverage diff@@ Coverage Diff @@
## main #PR +/-##
==========================================
+ Coverage 81.56% 81.57% +0.01%
==========================================
Files 428 428 —
Lines 29661 29666 +5
Branches 19429 19438 +9
==========================================
+ Hits 24194 24200 +6
- Misses 5467 5466 -1
- Partials 2024 2023 -1Generated by Codecov Action |
| const afterSlash = issueId.slice(slashIdx + 1); | ||
| if (afterSlash && !afterSlash.includes("-") && !isAllDigits(afterSlash)) { | ||
| // Bare suffix after org — guide user to supply a project | ||
| return `${base} ${command} ${prefix}/<project>-${afterSlash}`; |
There was a problem hiding this comment.
Bug: The buildCommandHint function generates an incorrect command hint for issue arguments combining an organization and a special selector (e.g., org/@latest), suggesting an invalid command format.
Severity: LOW
Suggested Fix
Modify the condition at line 103 in buildCommandHint to correctly handle special selectors like @latest. The check should be updated to ignore strings that start with @, preventing them from being treated as project suffixes. For example, add !afterSlash.startsWith('@') to the conditional. Additionally, add a test case for inputs like "sentry/@latest" to prevent future regressions.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.
Location: src/commands/issue/utils.ts#L102-L105
Potential issue: The new logic in the `buildCommandHint` function incorrectly handles
issue arguments that combine an organization with a special selector, such as
`"sentry/@latest"`. The condition at line 103 in `src/commands/issue/utils.ts` fails to
account for the `@` prefix in the part of the string after the slash. As a result, when
`buildCommandHint` is called with an input like `"sentry/@latest"`, it incorrectly
assumes `@latest` is a project suffix and generates a malformed command hint like
`"sentry issue view sentry/<project>-@latest"`. The correct behavior would be to return
`"sentry issue view sentry/@latest"`. This bug is triggered when selector resolution
fails and an error hint is generated for the user, leading to confusion.
Did we get this right? 👍 / 👎 to inform future reviews.
There was a problem hiding this comment.
Fixed in 721e4a2. The rewrite now skips @-prefixed segments, so sentry/@latest is shown as-is instead of being mangled into sentry/<project>-@latest. Added a regression test.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 39aa9ba. Configure here.
|
Jared resolve all the review comments |
…fix form Only rewrite the hint when the input is a true `org/suffix` (single slash, non-empty org, bare suffix). Skip `@` selectors (`org/@latest`), multi-segment paths (`org/project/id`), `#`-separated forms (`org/project#id`), dashed short IDs, and numeric IDs — all already fully specified or handled elsewhere. Addresses review comments from sentry[bot] and cursor[bot].

This PR addresses an issue where
buildCommandHintprovided an unhelpful error suggestion for issue IDs in theorg/SUFFIXformat (e.g.,sentry/SERVER).Problem: When a user provided an issue ID like
org/SERVER(a bare suffix after a slash),buildCommandHintincorrectly returned the raw input as a suggestion. This led to an unhelpfulResolutionErrormessage, as theTry:hint simply echoed the same failing command (sentry issue view sentry/SERVER) instead of guiding the user to the correct format (sentry issue view sentry/<project>-SERVER).Root Cause: The
buildCommandHintfunction had a short-circuiting logic that returned the rawissueIdif it contained a/, without further checking if the part after the slash was a valid project-prefixed suffix or a bare suffix.Solution: The logic within
buildCommandHinthas been updated. It now inspects the segment after the last/. If this segment is identified as a bare suffix (i.e., it contains no dash and is not composed purely of digits), the function constructs a more helpful hint:${base} ${command} ${org}/<project>-${suffix}. This ensures that users receive actionable advice when they omit the project prefix inorg/suffixissue ID formats, while preserving the correct behavior for other slash-containing inputs (e.g.,org/numeric,org/project-suffix).Fixes CLI-RD
Comment
@sentry <feedback>on this PR to have Autofix iterate on the changes.