Mem-Client: OAuth Redirect Resilience

Repository: mem-labs/mem

activeUpdated Feb 19, 2026, 8:40 PM

Name

Status

Markdown

OAuth redirect/callback flows must fail safely and visibly.

Rationale:
- OAuth callback failures should never strand users in silent or unrecoverable states.

Scope:
- PR review policy for runtime changes in:
  - `domains/frontend/mem-client/src/pages/google-oauth-redirect/**`
  - `domains/frontend/mem-client/src/pages/google-oauth-redirect-desktop/**`
  - `domains/frontend/mem-client/src/pages/integrations/calendar/*oauth-callback-page.tsx`
  - `domains/frontend/mem-client/src/pages/log-in-oauth-token/**`
- Includes changes to helpers imported by these routes when they affect callback error handling or navigation.

Trigger:
- A PR changes callback behavior in scope, including:
  - query/fragment param parsing,
  - OAuth code/state validation,
  - callback error handling,
  - navigation/deep-link fallback behavior,
  - rendered success/failure state behavior.

Definitions:
- Explicit navigation call: `navigate(...)`, `store.navigation.goTo*`, or `<Navigate ...>` in the failure path.
- User-visible feedback: toast/dialog/inline error UI or equivalent rendered error state visible without developer tools.

Approval checks:
1) Provider error-param failure paths include both user-visible feedback and explicit navigation.
2) Missing/invalid code/state failure paths include explicit navigation to a safe internal route.
3) External-navigation/deep-link paths include failure handling (`try/catch` or equivalent) with explicit internal-navigation fallback.
4) Tests for changed failure paths assert both failure feedback behavior and navigation/fallback outcome.

Evidence:
- Diff shows failure-path handling plus test assertions for changed branches.

Decision:
- Return NOT APPROVED when trigger is met and any required failure-handling assurance is missing.

Cancel