fix(cli): handle messaging-only workspaces#350
Conversation
|
Warning Review limit reached
Next review available in: 25 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthrough
ChangesMessaging-only workspace provisioning
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant User
participant relayfileLogin
participant AgentRelayResolver
participant RelaycastAPI
participant RelayfileCloud
participant CredentialStore
User->>relayfileLogin: login --provision-messaging-only
relayfileLogin->>AgentRelayResolver: resolve active workspace
AgentRelayResolver-->>relayfileLogin: messaging-only workspace error
relayfileLogin->>RelaycastAPI: verify workspace key
RelaycastAPI-->>relayfileLogin: messaging-only workspace
relayfileLogin->>RelayfileCloud: create Relayfile workspace
RelayfileCloud-->>relayfileLogin: workspace and delegated token
relayfileLogin->>CredentialStore: persist workspace and credentials
CredentialStore-->>User: login success guidance
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Relayfile Eval ReviewRun: Passed: 4 | Needs human: 0 | Reviewable: 0 | Missing output: 0 | Failed: 0 | Skipped: 0 Human Review CasesNo reviewable human-review cases captured Relayfile output. |
There was a problem hiding this comment.
Code Review
This pull request introduces support for detecting and handling messaging-only (Relaycast-only) workspaces. It adds error classification logic to identify when an active workspace is messaging-only or has an invalid key, and introduces a --provision-messaging-only flag to automatically provision a separate Relayfile-backed workspace. The feedback suggests wrapping the validation error with %w instead of %v in fmt.Errorf to follow Go best practices.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| return fmt.Errorf( | ||
| "the active Agent Relay workspace could not be resolved through Cloud, and Relayfile could not verify it with Relaycast: %v. Check network connectivity and try again", | ||
| validationErr, | ||
| ) |
There was a problem hiding this comment.
In Go, it is a best practice to wrap errors using %w instead of %v in fmt.Errorf when returning wrapped errors. This allows callers to inspect the underlying error using errors.Is or errors.As.
| return fmt.Errorf( | |
| "the active Agent Relay workspace could not be resolved through Cloud, and Relayfile could not verify it with Relaycast: %v. Check network connectivity and try again", | |
| validationErr, | |
| ) | |
| return fmt.Errorf( | |
| "the active Agent Relay workspace could not be resolved through Cloud, and Relayfile could not verify it with Relaycast: %w. Check network connectivity and try again", | |
| validationErr, | |
| ) |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e3b3c5caee
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| relayfileDefaultVersion = "0.10.17" | ||
| defaultServerURL = "https://file.agentrelay.com" | ||
| defaultCloudAPIURL = "https://agentrelay.com/cloud" | ||
| defaultRelaycastAPIURL = "https://gateway.relaycast.dev" |
There was a problem hiding this comment.
Point the Relaycast verifier at the hosted origin
When neither RELAYCAST_BASE_URL nor RELAY_BASE_URL is set, validateRelaycastWorkspaceKey will call https://gateway.relaycast.dev/v1/workspace. The published Relaycast OpenAPI server is https://cast.agentrelay.com/v1 (https://github.com/AgentWorkforce/relaycast/blob/main/openapi.yaml), so default installs send the validation request to the wrong origin and a messaging-only active workspace falls through as an unverifiable error instead of enabling the actionable message or --provision-messaging-only path. Default to the Relaycast hosted origin that this code appends /v1 to, or derive it from Agent Relay.
Useful? React with 👍 / 👎.
|
|
||
| var relayIntegrationBindingsMu sync.Mutex | ||
|
|
||
| var agentRelayWorkspaceKeyInResolverError = regexp.MustCompile(`(?:[?&]key=|/api/v1/workspaces/)(rk_live_[A-Za-z0-9_-]+)`) |
There was a problem hiding this comment.
Accept rk_test workspace keys in classification
In staging/dev, Relaycast workspace keys can be rk_test_* per the Relaycast OpenAPI, but this regexp only extracts rk_live_* and the later prefix check repeats that restriction. When Agent Relay's resolver 404 includes an rk_test_* key, the error won't be classified or redacted, so users see the opaque resolver failure (including the key) instead of the invalid-key/messaging-only remediation. Match all Relaycast workspace key prefixes the API accepts.
Useful? React with 👍 / 👎.
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 `@cmd/relayfile-cli/main.go`:
- Around line 112-114: Update agentRelayMessagingOnlyWorkspaceError and the
--workspace validation flow to retain the Relaycast workspace data.id alongside
messagingOnly.Name, then accept either the supplied workspace name or ID when
validating provision-messaging-only login. Preserve the existing typed-error
behavior and add coverage for the workspace-ID form in the relevant tests.
🪄 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: 0573c365-42eb-44b3-94dd-098cd5747441
📒 Files selected for processing (2)
cmd/relayfile-cli/main.gocmd/relayfile-cli/main_test.go
| type agentRelayMessagingOnlyWorkspaceError struct { | ||
| Name string | ||
| } |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Preserve the Relaycast workspace ID when validating --workspace.
--workspace accepts a name or ID (Line 2297), but validation discards data.id and compares only against messagingOnly.Name. Consequently, login --workspace <relaycast-id> --provision-messaging-only rejects the authenticated active workspace. Carry the ID in the typed error, accept either name or ID, and cover the ID form in tests.
Also applies to: 1334-1362, 1937-1942
🤖 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 `@cmd/relayfile-cli/main.go` around lines 112 - 114, Update
agentRelayMessagingOnlyWorkspaceError and the --workspace validation flow to
retain the Relaycast workspace data.id alongside messagingOnly.Name, then accept
either the supplied workspace name or ID when validating
provision-messaging-only login. Preserve the existing typed-error behavior and
add coverage for the workspace-ID form in the relevant tests.
There was a problem hiding this comment.
3 issues found across 2 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="cmd/relayfile-cli/main.go">
<violation number="1" location="cmd/relayfile-cli/main.go:50">
P1: The default Relaycast API URL `https://gateway.relaycast.dev` is a legacy domain that is being decommissioned. The current production Relaycast server is `https://cast.agentrelay.com`. With this default, the messaging-only workspace validation will fail on default installs (no env override), causing a verified messaging-only workspace to fall through as a network/verification error rather than triggering the actionable remediation message or `--provision-messaging-only` path.
Update to `https://cast.agentrelay.com` to match the published OpenAPI server URL.</violation>
<violation number="2" location="cmd/relayfile-cli/main.go:65">
P2: The regex and subsequent prefix check only handle `rk_live_*` workspace keys. If staging/dev environments use keys with a different prefix (e.g., `rk_test_*`), those will not be extracted or classified, causing the opaque resolver error—including the key itself—to be shown to users instead of the actionable remediation message. Consider matching all valid Relaycast key prefixes to ensure proper classification and key redaction in non-production environments.</violation>
<violation number="3" location="cmd/relayfile-cli/main.go:1938">
P2: The messaging-only workspace validation only compares `workspaceValue` against `messagingOnly.Name`, but `--workspace` accepts both a name and an ID. If a user passes `--workspace <relaycast-id>` with `--provision-messaging-only`, this comparison will always fail and reject the request even though the workspace is correctly authenticated. Consider also storing the Relaycast workspace ID in `agentRelayMessagingOnlyWorkspaceError` (from `payload.Data.ID` in `validateRelaycastWorkspaceKey`) and accepting either name or ID in this comparison.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| relayfileDefaultVersion = "0.10.17" | ||
| defaultServerURL = "https://file.agentrelay.com" | ||
| defaultCloudAPIURL = "https://agentrelay.com/cloud" | ||
| defaultRelaycastAPIURL = "https://gateway.relaycast.dev" |
There was a problem hiding this comment.
P1: The default Relaycast API URL https://gateway.relaycast.dev is a legacy domain that is being decommissioned. The current production Relaycast server is https://cast.agentrelay.com. With this default, the messaging-only workspace validation will fail on default installs (no env override), causing a verified messaging-only workspace to fall through as a network/verification error rather than triggering the actionable remediation message or --provision-messaging-only path.
Update to https://cast.agentrelay.com to match the published OpenAPI server URL.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At cmd/relayfile-cli/main.go, line 50:
<comment>The default Relaycast API URL `https://gateway.relaycast.dev` is a legacy domain that is being decommissioned. The current production Relaycast server is `https://cast.agentrelay.com`. With this default, the messaging-only workspace validation will fail on default installs (no env override), causing a verified messaging-only workspace to fall through as a network/verification error rather than triggering the actionable remediation message or `--provision-messaging-only` path.
Update to `https://cast.agentrelay.com` to match the published OpenAPI server URL.</comment>
<file context>
@@ -46,6 +47,7 @@ const (
relayfileDefaultVersion = "0.10.17"
defaultServerURL = "https://file.agentrelay.com"
defaultCloudAPIURL = "https://agentrelay.com/cloud"
+ defaultRelaycastAPIURL = "https://gateway.relaycast.dev"
defaultObserverURL = "https://agentrelay.com/observer/file"
minAgentRelayCLIVersion = "8.7.0"
</file context>
| defaultRelaycastAPIURL = "https://gateway.relaycast.dev" | |
| defaultRelaycastAPIURL = "https://cast.agentrelay.com" |
|
|
||
| var relayIntegrationBindingsMu sync.Mutex | ||
|
|
||
| var agentRelayWorkspaceKeyInResolverError = regexp.MustCompile(`(?:[?&]key=|/api/v1/workspaces/)(rk_live_[A-Za-z0-9_-]+)`) |
There was a problem hiding this comment.
P2: The regex and subsequent prefix check only handle rk_live_* workspace keys. If staging/dev environments use keys with a different prefix (e.g., rk_test_*), those will not be extracted or classified, causing the opaque resolver error—including the key itself—to be shown to users instead of the actionable remediation message. Consider matching all valid Relaycast key prefixes to ensure proper classification and key redaction in non-production environments.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At cmd/relayfile-cli/main.go, line 65:
<comment>The regex and subsequent prefix check only handle `rk_live_*` workspace keys. If staging/dev environments use keys with a different prefix (e.g., `rk_test_*`), those will not be extracted or classified, causing the opaque resolver error—including the key itself—to be shown to users instead of the actionable remediation message. Consider matching all valid Relaycast key prefixes to ensure proper classification and key redaction in non-production environments.</comment>
<file context>
@@ -60,6 +62,8 @@ var relayfileVersion = relayfileDefaultVersion
var relayIntegrationBindingsMu sync.Mutex
+var agentRelayWorkspaceKeyInResolverError = regexp.MustCompile(`(?:[?&]key=|/api/v1/workspaces/)(rk_live_[A-Za-z0-9_-]+)`)
+
// defaultJoinScopes are the scopes minted for every delegated-credential
</file context>
| return workspaceRecord{}, "", false, err | ||
| } | ||
| requested := strings.TrimSpace(workspaceValue) | ||
| if requested != "" && !strings.EqualFold(requested, "active") && requested != strings.TrimSpace(messagingOnly.Name) { |
There was a problem hiding this comment.
P2: The messaging-only workspace validation only compares workspaceValue against messagingOnly.Name, but --workspace accepts both a name and an ID. If a user passes --workspace <relaycast-id> with --provision-messaging-only, this comparison will always fail and reject the request even though the workspace is correctly authenticated. Consider also storing the Relaycast workspace ID in agentRelayMessagingOnlyWorkspaceError (from payload.Data.ID in validateRelaycastWorkspaceKey) and accepting either name or ID in this comparison.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At cmd/relayfile-cli/main.go, line 1938:
<comment>The messaging-only workspace validation only compares `workspaceValue` against `messagingOnly.Name`, but `--workspace` accepts both a name and an ID. If a user passes `--workspace <relaycast-id>` with `--provision-messaging-only`, this comparison will always fail and reject the request even though the workspace is correctly authenticated. Consider also storing the Relaycast workspace ID in `agentRelayMessagingOnlyWorkspaceError` (from `payload.Data.ID` in `validateRelaycastWorkspaceKey`) and accepting either name or ID in this comparison.</comment>
<file context>
@@ -1812,21 +1914,39 @@ func delegatedRelayfileTokenViaCloud(cloud cloudCredentials, workspaceID, agentN
+ return workspaceRecord{}, "", false, err
+ }
+ requested := strings.TrimSpace(workspaceValue)
+ if requested != "" && !strings.EqualFold(requested, "active") && requested != strings.TrimSpace(messagingOnly.Name) {
+ return workspaceRecord{}, "", false, fmt.Errorf("active messaging-only Agent Relay workspace %q does not match requested workspace %q", messagingOnly.Name, workspaceValue)
+ }
</file context>
|
ℹ️ pr-reviewer: review only — no file changes were applied to the PR (nothing to commit after review). The notes below are advisory and were not pushed. Review: PR #350 — fix(cli): handle messaging-only workspacesSummaryThis PR adds handling for the case where the active Agent Relay workspace is "messaging-only" (Relaycast-only, not Relayfile-backed). When
The scope is confined to VerificationRan the canonical CI steps end-to-end with Go 1.22 (the version pinned in
Traced all callers of the changed functions:
Safety assessmentThe change preserves fail-closed semantics — this is a security-sensitive area (credential/workspace resolution), and I checked it carefully:
No changes were made to lifecycle, termination, reaper, in-flight, dispatch, or broker-ownership code. Auto-applied fixesNone. The diff is mechanically clean (gofmt-aligned flag map, correct import ordering) and builds/tests pass as-is. There were no lint/format/typo issues to fix. Addressed comments
Advisory Notes
VerdictThe change is well-scoped, correctly preserves fail-closed behavior, has focused test coverage, and the full build + test suite passes. I could not confirm the state of GitHub CI checks or PR mergeability from within this sandbox (those are reported separately by cloud), so I am not asserting the PR is fully clear for a human hand-off. |
Summary
GET /v1/workspaceis classified as Relaycast-only.relayfile setup --workspace <name>.relayfile login --provision-messaging-only, which uses Relayfile's existing CloudPOST /api/v1/workspacescreate path, mints and persists delegated credentials, and continues with the new Relayfile workspace.Two-plane rationale
Agent Relay messaging workspaces and Cloud/Relayfile workspaces intentionally live on separate planes. This change does not modify Relay or Cloud, does not adopt a Relaycast key into Cloud, and does not rewrite the active Agent Relay workspace. The provisioning request contains only the workspace name; Cloud creates an independent Relayfile-backed workspace with its own
rw_...identity.Validation
go build ./...go test ./cmd/relayfile-cli -count=1go test ./...New tests cover the actionable messaging-only error (including absence of the opaque 404 and key), invalid-key non-misclassification, and the separate Cloud-create/delegated-credential path.