Repository navigation
Conversation
…inyhumansai#3025) On a cloud/self-hosted runtime, OAuth sign-in can complete in the browser yet the desktop shows "Sign-in failed. Please try again." with no guidance, while the same account signs in fine on the local runtime (tinyhumansai#3025). Investigation (no reproducible desktop bug): `auth_store_session` makes the core validate the fresh session token against the backend `GET /auth/me` before persisting. In cloud mode that runs on the user's *remote* core, so the failure is the remote runtime being unable to reach/authenticate the backend (misconfigured `BACKEND_URL`, offline, or a core predating `allowPendingBackendValidation`) — confirmed by a reporter whose fix was missing env settings. The desktop-side transport is correct: URL/token resolution prefers the stored cloud values and the RPC caches are busted before delivery. Change (safe, verifiable): - Add `authStoreFailureUserMessage(kind, mode)`: in cloud mode, replace the dead-end generic message with a message pointing at the remote runtime — token/backend hint for 401, connectivity/`BACKEND_URL` hint for gateway/timeout/network. Local/unset mode keeps the plain retry message. - Wire it into the deep-link auth-store catch path. - Document the failure and its remote-core causes in the cloud-deploy guide. Tests: unit coverage for the new message selector (local/unset stays generic; cloud is actionable and mode/kind-specific). Existing generic-message tests run with mode unset and are unaffected. Refs tinyhumansai#3025 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
📝 WalkthroughWalkthroughAdds an exported ChangesCloud-aware auth failure message
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant DeepLinkListener
participant AuthStoreFailureUserMessage
participant User
DeepLinkListener->>DeepLinkListener: classify failure kind
DeepLinkListener->>AuthStoreFailureUserMessage: authStoreFailureUserMessage(kind, mode)
alt mode is cloud
AuthStoreFailureUserMessage-->>DeepLinkListener: kind-specific remote guidance
else mode is local or null
AuthStoreFailureUserMessage-->>DeepLinkListener: generic retry message
end
DeepLinkListener->>User: failDeepLinkAuthProcessing(message)
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Comment |
…nyhumansai#3025) CI Frontend Checks flagged prettier formatting: hoist the shared kind list to a CLOUD_KINDS const (avoids the >100-col inline array) and trim two it() titles. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
app/src/utils/desktopDeepLinkListener.ts (2)
288-288: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueConsider logging the resolved mode for correlation.
console.warnat Line 287 logskindbut not themodeused to pick the message. Since the message text now branches heavily onmode, logging it alongsidekindwould help correlate cloud vs local failures in Sentry/console without extra effort.As per coding guidelines, "On new or changed flows, add verbose debug logging with stable prefixes, correlation fields, and no secrets or full PII; incomplete changes are those lacking logging."
🤖 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 `@app/src/utils/desktopDeepLinkListener.ts` at line 288, The deep-link auth failure logging in desktopDeepLinkListener should include the resolved mode used to choose the user-facing message, since the current warning only records kind. Update the existing console.warn/failure path around failDeepLinkAuthProcessing and authStoreFailureUserMessage to log both kind and the resolved getStoredCoreMode() result with a stable prefix, so cloud vs local failures can be correlated in Sentry/console without exposing secrets or PII.Source: Coding guidelines
337-364: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueNew user-facing strings bypass
useT().The new hardcoded English strings returned by
authStoreFailureUserMessageare surfaced directly to users viafailDeepLinkAuthProcessing, but this file already had this pattern pre-existing (e.g., Lines 193, 205, 262-267) prior to this change, so this is consistent with the file's established (non-i18n) convention rather than a net-new deviation. Flagging for awareness since the guideline requires all UI text go throughuseT()with keys added toen.tsand all locale files.As per coding guidelines, "All UI text must go through
useT()fromapp/src/lib/i18n/I18nContext, and new keys must be added toen.tsplus all locale files."🤖 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 `@app/src/utils/desktopDeepLinkListener.ts` around lines 337 - 364, The user-facing failure messages in authStoreFailureUserMessage are hardcoded English and should be routed through useT() instead of returning raw strings. Update authStoreFailureUserMessage and the call path in failDeepLinkAuthProcessing to fetch localized strings via i18n keys, then add the new keys to en.ts and every locale file so all surfaced deep-link auth errors are translated consistently.Source: Coding guidelines
🤖 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 `@app/src/utils/desktopDeepLinkListener.ts`:
- Line 288: The deep-link auth failure logging in desktopDeepLinkListener should
include the resolved mode used to choose the user-facing message, since the
current warning only records kind. Update the existing console.warn/failure path
around failDeepLinkAuthProcessing and authStoreFailureUserMessage to log both
kind and the resolved getStoredCoreMode() result with a stable prefix, so cloud
vs local failures can be correlated in Sentry/console without exposing secrets
or PII.
- Around line 337-364: The user-facing failure messages in
authStoreFailureUserMessage are hardcoded English and should be routed through
useT() instead of returning raw strings. Update authStoreFailureUserMessage and
the call path in failDeepLinkAuthProcessing to fetch localized strings via i18n
keys, then add the new keys to en.ts and every locale file so all surfaced
deep-link auth errors are translated consistently.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 10acc28b-adb5-4958-9998-17ce90c45208
📒 Files selected for processing (3)
app/src/utils/__tests__/desktopDeepLinkListener.test.tsapp/src/utils/desktopDeepLinkListener.tsgitbooks/features/cloud-deploy.md
2 participants
Symptom
On a cloud / self-hosted runtime, OAuth (Google/GitHub/Twitter) completes in the browser ("close this and return to the app"), but the desktop then shows "Sign-in failed. Please try again." — while the same account signs in fine on the local embedded runtime (#3025).
Investigation — no reproducible desktop bug
auth_store_sessionmakes the core validate the freshly minted session token against the backendGET /auth/mebefore persisting it (the team's own documented hypothesis, pinned indesktopDeepLinkListener.test.ts). In cloud mode that validation runs on the user's remoteopenhuman-core, so the dominant failure is the remote runtime being unable to reach/authenticate the backend:BACKEND_URLunset/wrong on the server — a reporter in the thread confirmed their fix was "missed certain default settings from the env."/auth/meallowPendingBackendValidation(validates synchronously)/rpcThe desktop transport is correct:
getCoreRpcUrl/getCoreRpcTokenprefer the stored cloud URL/token, the RPC caches are busted before session delivery (applySessionToken), and HTTPS cores are fetched directly (the reporter's "Test Connection" passed). So the desktop can't retry away the failure — but it was hiding the real cause behind a dead-end generic message.Change (safe, verifiable)
authStoreFailureUserMessage(kind, mode): in cloud mode, replace the generic message with an actionable one pointing at the remote runtime — token/backend hint for401, connectivity/BACKEND_URLhint for gateway/timeout/network, and a general "verify it's running & configured" fallback. Local/unset mode keeps the existing plain retry message.gitbooks/features/cloud-deploy.md.Tests
Unit coverage for the message selector: local/unset stays generic (existing assertions unaffected — they run with mode unset), cloud is actionable and mode/kind-specific.
Scope
This makes the cloud-mode failure diagnosable and actionable and documents the setup requirement; it does not claim to make a misconfigured/offline remote core validate sessions (that's a server-side config/version concern). Hence Refs #3025 rather than Closes — recommend keeping the issue open until the docs + message land and confirm the remaining reports are remote-core config.
Validation note
Per request, no tests were run locally — CI is authoritative. (The full Rust/
cargobuild is also blocked in my environment by a proxy TLS error on the CEF download.)🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Bug Fixes
Documentation