fix(deploy): prompt cloud login on integration auth failure#116
Conversation
📝 WalkthroughWalkthroughAdds interactive auth recovery for 401 failures during integration status checks, threads a mutable workspace token through deploy so recovered tokens can be retried and forwarded, and updates tests and CLI wiring to prompt/login and retry when allowed. ChangesAuth Recovery During Integration Connection
Sequence DiagramsequenceDiagram
participant CLI as CLI (runDeploy)
participant Deploy as deploy()
participant Integrations as connectIntegrations
participant Recovery as authRecovery.recover
participant Launcher as Launcher
CLI->>Deploy: call deploy(parsed, { authRecovery })
Deploy->>Deploy: activeToken = initial token
Deploy->>Integrations: check provider isConnected (uses token provider)
Integrations->>Integrations: isConnected → 401 unauthorized
Integrations->>Recovery: recover(workspace, provider, reason)
Recovery->>Recovery: prompt & ensureAuthenticated
Recovery-->>Deploy: return { token }
Deploy->>Integrations: retry isConnected (uses updated activeToken)
Integrations->>Integrations: isConnected → success
Deploy->>Launcher: launch with workspaceToken = activeToken
Launcher-->>CLI: launch result
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
f98af8e to
390cf56
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/deploy/src/connect.ts (1)
246-266:⚠️ Potential issue | 🟠 Major | ⚡ Quick winFail on unresolved status-check errors instead of offering a new connect flow.
checkProviderConnected()converts everyisConnected()exception intofalse, and Line 246 only treats auth-shaped messages as fatal. A 5xx/network/parsing failure will therefore fall through to the browser-connect path as if the provider were missing, which can create duplicate connections when the status API is merely unhealthy. After the recovery attempt, any remainingstatusCheckFailureshould produce a failed outcome.Suggested tightening
- if (statusCheckFailure && isIntegrationAuthFailure(statusCheckFailure)) { - input.io.error(`integrations.${provider}: auth failed while checking connection status`); + if (statusCheckFailure) { + input.io.error( + `integrations.${provider}: ${isIntegrationAuthFailure(statusCheckFailure) ? 'auth failed' : 'failed'} while checking connection status` + ); outcomes.push({ provider, status: 'failed', message: statusCheckFailure }); continue; }Also applies to: 345-357
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/deploy/src/connect.ts` around lines 246 - 266, checkProviderConnected() swallows non-auth isConnected() errors into statusCheckFailure, so after the auth-specific check (isIntegrationAuthFailure(statusCheckFailure)) you must treat any remaining statusCheckFailure as a fatal status-check error instead of proceeding to the browser-connect flow: when statusCheckFailure is truthy and not an auth error, log an error via input.io.error, push a failed outcome using the same outcome shape (provider, status: 'failed', message: statusCheckFailure) and then continue/return as appropriate (matching the current control flow used for auth failures); apply the same change to the analogous block around the other occurrence (lines handling the second provider check referenced in the review, e.g., the block at 345-357) so non-auth status-check failures never trigger a new connect flow.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/deploy/src/deploy.ts`:
- Around line 46-54: The recovery flow only assigns result.token to activeToken
but ignores result.workspace and result.cloudUrl from
CloudAuthRecoveryResolver.recover(), causing subsequent retries and the launcher
to use stale routing; either (A) propagate mutable workspace/cloudUrl through
the deploy state by updating the state variables (e.g., set the active workspace
and canonical cloud URL wherever the recover result is applied) so
retry/integration checks and the launcher pick up
result.workspace/result.cloudUrl, or (B) tighten the contract by removing
workspace/cloudUrl from the CloudAuthRecoveryResolver interface so callers can't
rely on them; update the code paths that currently take only result.token (the
places annotated in the review: around the recover result handling at lines
~46-54 and the other occurrences you noted) to implement one of these two
options and ensure retry logic and launcher initialization read the updated
deploy state values.
---
Outside diff comments:
In `@packages/deploy/src/connect.ts`:
- Around line 246-266: checkProviderConnected() swallows non-auth isConnected()
errors into statusCheckFailure, so after the auth-specific check
(isIntegrationAuthFailure(statusCheckFailure)) you must treat any remaining
statusCheckFailure as a fatal status-check error instead of proceeding to the
browser-connect flow: when statusCheckFailure is truthy and not an auth error,
log an error via input.io.error, push a failed outcome using the same outcome
shape (provider, status: 'failed', message: statusCheckFailure) and then
continue/return as appropriate (matching the current control flow used for auth
failures); apply the same change to the analogous block around the other
occurrence (lines handling the second provider check referenced in the review,
e.g., the block at 345-357) so non-auth status-check failures never trigger a
new connect flow.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: ef3ba0ec-fab8-4dd9-9af8-78c863e64556
📒 Files selected for processing (6)
packages/cli/src/deploy-command.tspackages/deploy/src/connect.test.tspackages/deploy/src/connect.tspackages/deploy/src/deploy.test.tspackages/deploy/src/deploy.tspackages/deploy/src/index.ts
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/deploy/src/deploy.test.ts`:
- Around line 392-400: The mock implementation of authRecovery.recover doesn't
match the CloudAuthRecoveryResolver return type; update the recover mock (in the
authRecovery object) so it returns a value conforming to Promise<{token:string;
workspace?:string}|false|null|undefined> — e.g., return false (or return {
token: 'fresh-token' } wrapped in a Promise-compatible value if you expect
success) and ensure the async function signature and the recovered
flag/assertions remain consistent with that chosen return value.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: fac70c86-6adf-40c6-b7a2-a8071e07417d
📒 Files selected for processing (6)
packages/cli/src/deploy-command.tspackages/deploy/src/connect.test.tspackages/deploy/src/connect.tspackages/deploy/src/deploy.test.tspackages/deploy/src/deploy.tspackages/deploy/src/index.ts
🚧 Files skipped from review as they are similar to previous changes (4)
- packages/cli/src/deploy-command.ts
- packages/deploy/src/index.ts
- packages/deploy/src/connect.ts
- packages/deploy/src/deploy.ts
2e09f34 to
ec1ce93
Compare
There was a problem hiding this comment.
🧹 Nitpick comments (1)
packages/deploy/src/connect.test.ts (1)
247-263: ⚡ Quick winIsolate
--no-promptbehavior from--no-connectin this test.This case sets both
noPrompt: trueandnoConnect: true, so it can pass due tonoConnectshort-circuiting rather than proving auth recovery is suppressed by--no-prompt. SetnoConnect: falseto keep the assertion targeted to the flag named in the test.Proposed test tweak
- noConnect: true, + noConnect: false, noPrompt: true,🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/deploy/src/connect.test.ts` around lines 247 - 263, The test "connectIntegrations does not prompt auth recovery when --no-prompt is set" wrongly sets both noPrompt: true and noConnect: true, letting noConnect short-circuit the code path; update the test invocation of connectIntegrations to set noConnect: false (leave noPrompt: true) so the test actually exercises suppression of auth recovery by --no-prompt (refer to the test name and the connectIntegrations call with the noPrompt/noConnect flags and the recoverCalled assertion).
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@packages/deploy/src/connect.test.ts`:
- Around line 247-263: The test "connectIntegrations does not prompt auth
recovery when --no-prompt is set" wrongly sets both noPrompt: true and
noConnect: true, letting noConnect short-circuit the code path; update the test
invocation of connectIntegrations to set noConnect: false (leave noPrompt: true)
so the test actually exercises suppression of auth recovery by --no-prompt
(refer to the test name and the connectIntegrations call with the
noPrompt/noConnect flags and the recoverCalled assertion).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 6b620d64-73e9-47b1-a61d-ee1d515cdaf1
📒 Files selected for processing (6)
packages/cli/src/deploy-command.tspackages/deploy/src/connect.test.tspackages/deploy/src/connect.tspackages/deploy/src/deploy.test.tspackages/deploy/src/deploy.tspackages/deploy/src/index.ts
🚧 Files skipped from review as they are similar to previous changes (5)
- packages/cli/src/deploy-command.ts
- packages/deploy/src/index.ts
- packages/deploy/src/deploy.test.ts
- packages/deploy/src/deploy.ts
- packages/deploy/src/connect.ts
Summary
Verification