[svc-agent]

Hotfix to main for TECH-807, already on staging (6e443d1, 29c5cf4). After merge, main and staging hold identical files.

Problem

1. NodeOAuthClient ran without a requestLock. Two Vercel instances could refresh the same session at once. Refresh tokens rotate, so the second refresh replays a used token, the authorization server revokes the session, and the user is signed out. The client logged "No lock mechanism provided. Credentials might get revoked." on every new instance.
2. Found in review: the xrpc proxy (reads and writes) and onboarding/clone-blob deleted the app session on any client.restore() error. A short outage fetching the authorization server's metadata, an Upstash error or a lock timeout signed the user out. The 28 Oct staging sign-out followed exactly that metadata error on /api/xrpc/...getSession.

Fix

Request lock (src/lib/auth/request-lock.ts, passed as requestLock)

• Calls on one instance queue in-process (requestLocalLock). Across instances the lock is oauth:lock:<name> in the existing Upstash Redis: SET NX PX 15000 with a random owner token, released by an owner-checked EVAL.
• The holder renews the TTL every 5s (owner-checked PEXPIRE). The token refresh has no timeout of its own, and with a lock configured the client no longer recovers from a concurrent refresh, so the lock must stay held for as long as the holder works. The 15s TTL only bounds how long a crashed holder blocks.
• Polling starts at 5ms and backs off to 150ms. Waiters give up after 45s with RequestLockTimeoutError.
• If a SET returns null but the key already holds our token (the Upstash client retried after a lost response), it counts as acquired.

Restore failures (src/lib/auth/restore-error.ts)

• isSessionGone(err, did) is used by /api/auth/session, both xrpc paths and clone-blob. Revoked/invalid/unrefreshable tokens, 401/403 and the existing message check delete the session and answer 401. Everything else keeps it and answers 503 (sessionUnavailable()), which authFetch does not treat as signed out.
• The client reports a failed session-store read as "The session was deleted by another process", the same error as a really missing session. That one error is checked against Redis before deleting.

Also included: scripts/verify-created-via.mjs accepts a PDS service id given as the full DID URL (did:plc:...#atproto_pds). Found by Greptile on #254 after it merged; staging 188008f7.

Testing

• Lock tests with a fake Redis that applies the scripts' owner check only when the script contains it. They cover holding across an async fn, fresh tokens, waiting for another instance, not deleting a taken-over lock, release on throw, in-process queueing, lost SET responses, renewal and its stop, and the 45s wait boundary. Each of these fails a test when broken on purpose: release without owner check, dropping await fn(), a shorter wait, no renewal, a constant token, no self-acquire check, an uncleared renew timer.
• Classifier tests, plus xrpc GET/POST and clone-blob tests for transient vs. revoked restores. The transient cases fail on the old routes.
• tsc, typecheck:test, lint, lint:css, 1423 unit tests, build.
• Staging (6e443d1): the deployment with the lock builds the client and logs no "No lock mechanism provided".

Not yet verified

The lock against real Upstash under a signed-in session (local .env.local has placeholder Upstash credentials). After a signed-in browse, check the logs for RequestLockTimeoutError, [oauth-lock] renew failed or [oauth-lock] release failed.

Reviewed by three subagents (atproto client internals, production failure modes, tests); this revision addresses their findings.

🤖 Generated with Claude Code

Confidence Score: 3/5

Fix lost-lock behavior and group-route session deletion before merging.

Findings

1.  Refreshes outlive the lock ▶
2.  Group timeouts delete valid sessions ▶

Fix with agent prompt

### Issue 1
src/lib/auth/request-lock.ts:84-88
If Redis renewal fails for more than 15 seconds while a refresh is still running, the key expires and another instance can refresh the same token. The first holder keeps running: renewal errors only log, and a renewal result of `0` is ignored. The overlapping refreshes can replay a rotating token and revoke the session.

Bound the refresh work and handle lost ownership explicitly rather than continuing under an expired lock.

### Issue 2
src/lib/auth/oauth-client.ts:122
Adding `redisRequestLock` introduces `RequestLockTimeoutError` into group requests, but `getAuthenticatedAgent` still calls `deleteSession()` after every restore error. If another instance holds the lock for 45 seconds, a request such as `/api/groups/memberships` deletes a valid app session and returns 401 instead of keeping it and returning 503.

Apply the shared error check to the group helper and preserve the temporary-failure response through its callers.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

Adds a Redis-backed OAuth lock and keeps app sessions through temporary restore failures in the XRPC and clone-blob routes. The verifier also accepts full-DID PDS service IDs.

• OAuth session restores wait their turn across server instances.
• Temporary restore failures no longer sign users out.
• The verification script finds a PDS by either service-ID form.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Restore OAuth session] --> B[Local queue]
  B --> C[Acquire Redis lock]
  C --> D[Read session and refresh if needed]
  D --> E[Renew lock while working]
  D --> F[Release owned lock]
  C -->|45-second wait expires| G[RequestLockTimeoutError]
  G --> H[XRPC and clone-blob keep session]
  G --> I[Group helper deletes session]
  E -->|Renewal fails and key expires| J[Another instance can acquire]
  J --> K[Refresh work can overlap]

Loading

_{Reviews (1) · Last reviewed commit: "fix(auth): keep sessions through transie..." · Reviewed by Greptile}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
certified-app	Ready	Preview	Oct 29, 2026 1:17pm UTC

[coderabbitai]

Caution

Review failed

The pull request is closed.

Finishing Touches

📝 Generate docstrings

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[greptile-apps]

Refreshes outlive the lock

If Redis renewal fails for more than 15 seconds while a refresh is still running, the key expires and another instance can refresh the same token. The first holder keeps running: renewal errors only log, and a renewal result of 0 is ignored. The overlapping refreshes can replay a rotating token and revoke the session.

Bound the refresh work and handle lost ownership explicitly rather than continuing under an expired lock.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/lib/auth/request-lock.ts
Line: 84-88

Comment:
**Refreshes outlive the lock**

If Redis renewal fails for more than 15 seconds while a refresh is still running, the key expires and another instance can refresh the same token. The first holder keeps running: renewal errors only log, and a renewal result of `0` is ignored. The overlapping refreshes can replay a rotating token and revoke the session.

Bound the refresh work and handle lost ownership explicitly rather than continuing under an expired lock.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

[greptile-apps]

Group timeouts delete valid sessions

Adding redisRequestLock introduces RequestLockTimeoutError into group requests, but getAuthenticatedAgent still calls deleteSession() after every restore error. If another instance holds the lock for 45 seconds, a request such as /api/groups/memberships deletes a valid app session and returns 401 instead of keeping it and returning 503.

Apply the shared error check to the group helper and preserve the temporary-failure response through its callers.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/lib/auth/oauth-client.ts
Line: 122

Comment:
**Group timeouts delete valid sessions**

Adding `redisRequestLock` introduces `RequestLockTimeoutError` into group requests, but `getAuthenticatedAgent` still calls `deleteSession()` after every restore error. If another instance holds the lock for 45 seconds, a request such as `/api/groups/memberships` deletes a valid app session and returns 401 instead of keeping it and returning 503.

Apply the shared error check to the group helper and preserve the temporary-failure response through its callers.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.