Skip to content

fix(deploy): prompt cloud login on integration auth failure#116

Merged
khaliqgant merged 2 commits into
mainfrom
codex/deploy-v1-review-feedback-workforce
May 13, 2026
Merged

fix(deploy): prompt cloud login on integration auth failure#116
khaliqgant merged 2 commits into
mainfrom
codex/deploy-v1-review-feedback-workforce

Conversation

@khaliqgant
Copy link
Copy Markdown
Member

Summary

  • prompt interactive deploy users to run the established Agent Relay Cloud browser login when integration status checks return 401
  • refresh the bearer token used by cloud integration checks and retry the status check once
  • preserve --no-prompt fail-fast behavior and add regression coverage for token refresh/retry paths

Verification

  • corepack pnpm --filter @agentworkforce/deploy test
  • corepack pnpm --filter @agentworkforce/cli test

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented May 13, 2026

Review Change Stack

📝 Walkthrough

Walkthrough

Adds 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.

Changes

Auth Recovery During Integration Connection

Layer / File(s) Summary
Auth Recovery Contracts
packages/deploy/src/connect.ts, packages/deploy/src/deploy.ts, packages/deploy/src/index.ts
New IntegrationAuthRecoveryResolver and CloudAuthRecoveryResolver interfaces are declared and re-exported; small type imports wired across modules.
Per-request workspace token resolution
packages/deploy/src/connect.ts
relayfileIntegrationResolver accepts `workspaceToken: string
ConnectIntegrations recovery logic
packages/deploy/src/connect.ts
ConnectAllInput gains authRecovery; connectIntegrations centralizes status checks, treats 401 as unauthorized-only, calls authRecovery.recover(...) when prompts allowed, and retries the check once; helper added for consistent check/logging.
Deploy integration and mutable token
packages/deploy/src/deploy.ts
deploy() normalizes cloudUrl, uses a mutable activeToken, passes a token-provider to integration resolver, and adapts CloudAuthRecoveryResolver into IntegrationAuthRecoveryResolver to update activeToken on recovery; launcher receives updated token.
CLI recovery implementation
packages/cli/src/deploy-command.ts
runDeploy passes createDeployAuthRecovery() to deploy; createDeployAuthRecovery forces auth, normalizes API URL, updates workspace pointer, logs progress, and returns { token } for retry.
Test coverage
packages/deploy/src/connect.test.ts, packages/deploy/src/deploy.test.ts
Tests added/updated: per-request workspaceToken invocation; connectIntegrations unauthorized→recover+retry flow; noPrompt fast-fail behavior; non-401 failure handling; cloud-mode deploy recovery test mocking 401→success and asserting recovered token forwarded.

Sequence Diagram

sequenceDiagram
  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
Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

Possibly related PRs

Poem

🐰 I nibbled on a token, found a 401 wall,

I twitched my nose, said "login!" and answered the call.
Fresh token in paw, the retry took flight,
Integrations rejoiced — the launcher lit bright.
If noPrompt stands firm, we bow out polite.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 17.65% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly and concisely summarizes the main change: prompting cloud login when integration auth fails during deploy operations.
Description check ✅ Passed The description is directly related to the changeset, detailing the specific improvements made (cloud login prompting, token refresh/retry, prompt preservation) and verification steps.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch codex/deploy-v1-review-feedback-workforce

Comment @coderabbitai help to get the list of available commands and usage tips.

@khaliqgant khaliqgant force-pushed the codex/deploy-v1-review-feedback-workforce branch from f98af8e to 390cf56 Compare May 13, 2026 17:36
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 win

Fail on unresolved status-check errors instead of offering a new connect flow.

checkProviderConnected() converts every isConnected() exception into false, 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 remaining statusCheckFailure should 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

📥 Commits

Reviewing files that changed from the base of the PR and between 8d98804 and f98af8e.

📒 Files selected for processing (6)
  • packages/cli/src/deploy-command.ts
  • packages/deploy/src/connect.test.ts
  • packages/deploy/src/connect.ts
  • packages/deploy/src/deploy.test.ts
  • packages/deploy/src/deploy.ts
  • packages/deploy/src/index.ts

Comment thread packages/deploy/src/deploy.ts
Copy link
Copy Markdown
Contributor

@devin-ai-integration devin-ai-integration Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 5 additional findings.

Open in Devin Review

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

📥 Commits

Reviewing files that changed from the base of the PR and between f98af8e and 390cf56.

📒 Files selected for processing (6)
  • packages/cli/src/deploy-command.ts
  • packages/deploy/src/connect.test.ts
  • packages/deploy/src/connect.ts
  • packages/deploy/src/deploy.test.ts
  • packages/deploy/src/deploy.ts
  • packages/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

Comment thread packages/deploy/src/deploy.test.ts
@khaliqgant khaliqgant force-pushed the codex/deploy-v1-review-feedback-workforce branch from 2e09f34 to ec1ce93 Compare May 13, 2026 17:49
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
packages/deploy/src/connect.test.ts (1)

247-263: ⚡ Quick win

Isolate --no-prompt behavior from --no-connect in this test.

This case sets both noPrompt: true and noConnect: true, so it can pass due to noConnect short-circuiting rather than proving auth recovery is suppressed by --no-prompt. Set noConnect: false to 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

📥 Commits

Reviewing files that changed from the base of the PR and between 2e09f34 and ec1ce93.

📒 Files selected for processing (6)
  • packages/cli/src/deploy-command.ts
  • packages/deploy/src/connect.test.ts
  • packages/deploy/src/connect.ts
  • packages/deploy/src/deploy.test.ts
  • packages/deploy/src/deploy.ts
  • packages/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

@khaliqgant khaliqgant merged commit 94cc423 into main May 13, 2026
2 checks passed
@khaliqgant khaliqgant deleted the codex/deploy-v1-review-feedback-workforce branch May 13, 2026 17:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant