feat(issue): link and unlink external issues and GitHub PRs - #1559
feat(issue): link and unlink external issues and GitHub PRs#1559betegon wants to merge 6 commits into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
betegon
changed the title
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
| const matches = links.filter( | ||
| (link) => | ||
| (!appSlug || link.serviceType === appSlug) && | ||
| parseTarget(link.webUrl).identity === target.identity | ||
| ); |
There was a problem hiding this comment.
Bug: The CLI can show a misleading error blaming user input when an existing, stored app link URL is malformed, preventing further actions on the issue.
Severity: MEDIUM
Suggested Fix
Wrap the parseTarget(link.webUrl) call within findAppIssueLink in a try-catch block. If an error is caught, provide a more informative message indicating that an existing link has an invalid URL, rather than blaming the user's current input.
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: packages/cli/src/lib/api/issue-app-links.ts#L174-L178
Potential issue: The `findAppIssueLink` function calls `parseTarget` on `webUrl` values
fetched from the API. If a stored `webUrl` is malformed (e.g., from a buggy integration
or old data), `parseTarget` throws an error. This error incorrectly suggests the user's
current input is invalid, rather than indicating a problem with pre-existing data. This
can block users from unlinking or relinking issues if a corrupt link is present. A
similar issue exists in `linkAppIssue` when validating an app's response post-mutation.
Also affects:
packages/cli/src/lib/api/issue-app-links.ts:711~715
Did we get this right? 👍 / 👎 to inform future reviews.
| const pending = fields.filter( | ||
| (field) => field === targetField || values[field.name] !== undefined | ||
| ); | ||
| const resolved = new Set<string>(); | ||
| while (pending.length) { | ||
| const index = pending.findIndex((item) => | ||
| (item.depends_on ?? []).every((name) => resolved.has(name)) | ||
| ); | ||
| const field = pending[index]; | ||
| if (!field) { |
There was a problem hiding this comment.
Bug: When a target field's dependency is not provided by the user, a misleading "circular dependencies" error is shown instead of a helpful "missing field" message.
Severity: LOW
Suggested Fix
Modify the logic in resolveFields to ensure all required fields, including dependencies of the target field, are added to the initial pending list. This will allow the dependency resolution loop to correctly identify and prompt for the missing fields, rather than failing with a misleading error.
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: packages/cli/src/lib/api/issue-app-links.ts#L476-L485
Potential issue: In the `resolveFields` function, if a target field has a dependency
(`depends_on`) and the user does not provide a value for that dependency, the dependency
resolution logic fails. The loop checking for dependencies returns `-1`, causing a
generic "missing or circular dependencies" error to be thrown. This masks the real
issue, which is a missing required field. The more specific error message, which lists
the missing fields, is never reached.
Did we get this right? 👍 / 👎 to inform future reviews.
2 participants
Adds
sentry issue link/unlink <issue> <url>for existing tracker issues and GitHub pull requests. Supports native GitHub, GitHub Enterprise, Jira, Jira Server, GitLab, Bitbucket and Azure DevOps integrations, plus Linear and compatible installed Sentry Apps.Links are external references: they do not create or delete remote tickets, mark PRs as fixes, or resolve the Sentry issue. Both commands support
--dry-runand JSON output. Existing or absent links are successful no-ops; unlink uses stored associations without fetching the remote ticket.GitHub
/pull/Nand/issues/Nidentify the same resource. GitLab resolves the exact project URL through the installation's repository search and sends its numeric project ID, supporting deployment prefixes and nested projects. Compatible Apps accept explicit issue select IDs or labels through--field, while preserving Linear identity checks and validating the callback's returned URL.Default OAuth requests
event:writefor linking and unlinking, plusorg:readfor repository and App discovery. It no longer requestsevent:admin; older Sentry versions may still require that scope explicitly for unlinking. Scope recovery preserves custom grants, and effective project permissions still apply.Uses
@sentry/apiwhere available and the existing HTTP helper for private operations absent from the SDK. Preflights bypass stale cache and mutations disable automatic retries. App linking checks for another existing target before calling the app, but concurrent replacements are not atomic. Generated CLI SDK types preserve repeated--fieldvalues. Commit references and resolution workflows remain outside this change.Validation:
TZ=UTC: 9,606 passed, 17 skipped.event:writeand succeeded after explicitly authorizingevent:admin. Production validation of write-only unlink remains pending; the merged backend permission change is covered by its regression tests.