fix(deploy): point harness probe + existing-persona lookup at real cloud routes#119
Merged
Merged
Conversation
The harness-credentials check called
`GET /api/v1/users/me/provider_credentials?model_provider=<provider>`,
which doesn't exist on cloud at all — the route was never built. Every
`agentworkforce deploy --harness-source oauth --no-prompt` therefore
failed with "credentials are not connected" even when they were, and
the auto-detect path (no --harness-source) always fell through to the
interactive prompt for the same reason.
Cloud actually exposes harness connection state via `/api/v1/cloud-agents`,
which returns one row per (user, workspace, harness). When the OAuth
completion route (`/api/v1/cli/auth/complete`) stores a credential in
S3 it marks that row `status: "connected"`. That's the single source
of truth — no second probe needed.
Changes:
* Replace `ProviderCredentialsResponse`+`providerCredentialsReady` with
`CloudAgentsListResponse`+`hasConnectedHarness`.
* Switch `isHarnessOauthConnected` to call `/api/v1/cloud-agents` and
match by harness (case-insensitive) + `status === 'connected'`.
* Rewrite the two existing harness tests for the new endpoint, plus add
two new cases: (1) a matching connected entry → probe returns true and
no connect-provider call fires; (2) entries with wrong harness or
wrong status are correctly ignored.
Plan/byok save paths still call cloud routes that don't exist either —
those need cloud-side implementation, deferred to a separate PR. Users
who already authed via `agent-relay cloud connect <provider>` (the
default flow today) are unblocked immediately by this change.
Smoke verified against `agentrelay.com/cloud` with the user's actual
Anthropic-connected workspace:
cloud: claude credentials already connected
(deploy proceeds to bundle/upload; the next failure is a separate 403
on `/workspaces/{ws}/agents` — cloud auth scope bug, not this PR.)
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughOAuth harness connection readiness check migrated from probing provider credentials to cloud agents endpoint. Type contracts added, readiness predicate replaced, and test suite expanded to cover harness matching, connection status, and polling behavior. ChangesCloud Agents OAuth Readiness Migration
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 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)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint skipped: no ESLint configuration detected in root package.json. To enable, add Comment |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
khaliqgant
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two phantom-endpoint bugs were blocking every
agentworkforce deployagainst production cloud. Both fall under the deploy-v1 "M3" rollout — workforce was wired to API routes that were never built on cloud, and the real routes have different paths/shapes.GET /users/me/provider_credentials?model_provider=<provider>GET /api/v1/cloud-agents, match by harness +status === 'connected'GET /workspaces/{ws}/agents?persona_slug=<slug>GET /workspaces/{ws}/deployments, filter client-sideWhy
Harness probe (1st commit)
User had Anthropic connected via
agent-relay cloud connect anthropic(status:"connected",credentialStoredAt:"2026-05-13T14:17:40.048Z"in cloud_agents). But every deploy with--no-promptfailed with "credentials are not connected" because the probe URL 404'd →isHarnessOauthConnectedreturned false →--no-promptshort-circuited to the actionable-but-misleading error.Existing-persona check (2nd commit)
agents.personaIdon the cloud schema is a UUID FK topersonas.id. The CLI only knows the persona's slug (persona.idin the JSON). Two interacting problems:/workspaces/{ws}/agentsis a dashboard proxy that requires session auth → 403 forcli:authBearer./workspaces/{ws}/deployments(cloud#580) acceptscli:authbut its?personaId=filter expects a UUID. Sending a slug → drizzle UUID-cast → 500.The fix is to fetch the workspace's full deployments list (bounded — dozens of rows in practice) and match client-side against
deployedName(which cloud derives frompersona.slug || persona.name || persona.id), withpersonaSlugandpersonaIdas fallbacks.Changes
Harness probe (1st commit):
ProviderCredentialsResponse+providerCredentialsReadywithCloudAgentsListResponse+hasConnectedHarness(body, expectedHarness).isHarnessOauthConnectednow hits/api/v1/cloud-agentsand matches by harness (case-insensitive) +status === 'connected'.Existing-persona check (2nd commit):
findExistingAgentnow calls/deployments(no server-side filter — see above).parseAgentLikeaccepts both{agentId, deployedName, personaId, status}(new) and{id, status}(legacy preview).expectedPersonaIdis supplied: match against any persona-identifying field on the row; rows with no persona info pass through (legacy back-compat).status === 'destroyed'as "not present" so re-deploys don't trip on-exists against tombstones.Tests
88 deploy tests pass. Combined coverage:
{agents:[{agentId,...}]}) parsed correctly; tombstones + wrong-persona rows skipped; legacy{agent:{id}}still works; listing GET fires before deploy POST.Many existing tests updated to disambiguate
init.method === 'GET'(listing) frominit.method === 'POST'(deploy) since both now share the same URL.Smoke
Built locally and ran against
https://agentrelay.com/cloudwith the actual user workspace50587328-...:Scope notes (deferred)
/workspaces/{ws}/provider-credentials/managedand/byok). Need cloud-side implementation. Out of scope.?personaId=filter on cloud's/deploymentsGET should accept slugs (currently UUID-only → 500 on slug input). Filed as a follow-up.@parcel/watcher-linux-x64-glibcmissing from cloud's Lambda bundle. Filed as a follow-up.Test plan
pnpm -F @agentworkforce/deploy run lintcleanpnpm -F @agentworkforce/deploy run test— 88/88 passagentrelay.com/cloudwith real workspace — harness check passes, existing-persona check passes, deploy bundle uploads (fails further down on cloud's packaging issue, not this PR)🤖 Generated with Claude Code