feat(init): resolve projects and improve existing setups - #1374
Conversation
41c51ff to
3263729
Compare
betegon
changed the title
3263729 to
2458762
Compare
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
2458762 to
504e0cb
Compare
betegon
changed the title
504e0cb to
a794d55
Compare
…ct-create-resolver
…ct-create-resolver # Conflicts: # packages/cli/src/lib/init/tools/apply-patchset.ts # packages/cli/src/lib/init/tools/registry.ts # packages/cli/src/lib/init/ui/ink-app.tsx # packages/cli/src/lib/init/ui/wizard-store.ts # packages/cli/src/lib/init/wizard-runner.ts # packages/cli/src/lib/init/workflow-inputs.ts # packages/cli/test/lib/init/wizard-runner.test.ts
…ct-create-resolver
…esolver' into refactor/shared-project-create-resolver
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
betegon
changed the title
| opts.existingProject.projectSlug === slug | ||
| ? opts.existingProject | ||
| : await tryGetExistingProjectData(opts.org, slug).catch(() => null); | ||
| const existingProject = await tryGetExistingProjectData(opts.org, slug); |
There was a problem hiding this comment.
Bug: The resolveExistingProjectChoice and findAvailableProjectSlug functions don't handle API errors from tryGetExistingProjectData, causing the wizard to crash on transient network or server issues.
Severity: HIGH
Suggested Fix
Wrap the calls to tryGetExistingProjectData within resolveExistingProjectChoice and findAvailableProjectSlug in try...catch blocks. The catch block should handle the ApiError gracefully, perhaps by logging the error and returning a failure state or re-throwing a more specific WizardError that the top-level runner can interpret, rather than letting the wizard crash.
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/init/preflight.ts#L356
Potential issue: The functions `resolveExistingProjectChoice` and
`findAvailableProjectSlug` both call `tryGetExistingProjectData` without handling
potential non-404 API errors. `tryGetExistingProjectData` is designed to throw an
`ApiError` for issues like network failures, timeouts, or 5xx server errors. Because
these calls are not wrapped in a `try...catch` block, any such transient API error will
propagate up the call stack. This causes the `sentry init` wizard to crash with an
unhandled exception instead of gracefully handling the failure, for example, by retrying
or informing the user. This can happen during explicit project selection or when the
wizard is automatically searching for an available project slug.
Also affects:
packages/cli/src/lib/init/preflight.ts:569~575
…ct-create-resolver # Conflicts: # packages/cli/src/lib/init/clack-utils.ts
| opts.existingProject.projectSlug === slug | ||
| ? opts.existingProject | ||
| : await tryGetExistingProjectData(opts.org, slug).catch(() => null); | ||
| const existingProject = await tryGetExistingProjectData(opts.org, slug); |
There was a problem hiding this comment.
Bug: The resolveExistingProjectChoice function lacks error handling for API calls. Any non-404 API error during project lookup will cause an unhandled exception, crashing the init wizard.
Severity: HIGH
Suggested Fix
Wrap the call to tryGetExistingProjectData within a try-catch block to handle potential API errors gracefully. Similar to the previous implementation, catching errors and returning null would prevent the wizard from crashing and allow the flow to continue, for example, by falling back to project creation.
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/init/preflight.ts#L356
Potential issue: The function `resolveExistingProjectChoice` at `preflight.ts:356` calls
`tryGetExistingProjectData` without a `try-catch` block. The `tryGetExistingProjectData`
function is designed to only handle 404 errors and rethrows all other exceptions, such
as 401, 403, 5xx, or network errors. Consequently, any transient API failure during the
existing project lookup will cause an unhandled exception. This will crash the `sentry
init` wizard instead of allowing it to gracefully handle the error, for instance, by
proceeding to the project creation step. The previous implementation included a
`.catch(() => null)` which prevented this crash.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 5036a86. Configure here.
| // token's OAuth upper bound is stale, not that another route can work. | ||
| if (team.source !== "explicit" && isMemberCreationDisabled403(error)) { | ||
| throw buildTeamAdminAuthorizationError(orgSlug, team.slug); | ||
| } |
There was a problem hiding this comment.
Batch reuses org-scoped team incorrectly
Medium Severity
createProjectWithTeamFallback treats an auto-created team like one chosen from Team Admin access and turns a member-creation-disabled 403 into a hard authorization error instead of falling back to the org-scoped route. In a multi-project batch, the first project can succeed via org-scoped personal-team creation, then later projects reuse that auto-created team through the team-scoped path and fail even though org-scoped creation would still work.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 5036a86. Configure here.
| this.completedPrompt = prompt; | ||
| this.store.holdPresentation(); | ||
| resolve(value as T); | ||
| return; |
There was a problem hiding this comment.
Presentation hold blocks completion UI
Medium Severity
holdPresentationOnResolve freezes the visible snapshot and clears activePromptCancel, but hold is released only when a later non-null setPrompt runs. setOutro and setPrompt(null) do not clear presentationHold, so if the workflow finishes, errors, or is cancelled before another prompt mounts, AppBody keeps rendering the frozen pre-hold frame and never shows the completion screen.
Additional Locations (2)
Reviewed by Cursor Bugbot for commit 5036a86. Configure here.
1 participant
Summary
sentry initto creating a new project unless repository signals resolve one existing project unambiguouslysentry initandsentry project create, including Team Admin handling and safe non-interactive behaviorOAuth companion
#1373 adds
team:adminto the standard OAuth scope set for new grants and refreshes eligible existing interactive grants once after a scope-specific 403. Unattended, JSON/non-interactive, dry-run, and effective environment-token execution do not start OAuth.Test plan
pnpm typecheckCloses #1375.
The terminal-height overflow remains separate in #1376.