Recover Redis-backed admission after connection loss - #14
Conversation
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
There was a problem hiding this comment.
馃挕 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d0cc495689
鈩癸笍 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".
|
@codex review |
|
Codex Review: Didn't find any major issues. Already looking forward to the next diff. Reviewed commit: 鈩癸笍 About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
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". |
What Changed
503 Service Unavailableresponses withRetry-Afteracross endpoint creation, webhook capture, event streams, and request replay.Why
The rate-limit layer cached one Redis client promise for the lifetime of the web process. When that client lost its connection, commands could accumulate in the default offline queue and fail after a long timeout while the cached client remained unusable. Existing logged-in sessions could appear healthy because they reused persisted endpoints, while brand-new sessions immediately exercised the broken endpoint-creation path.
This change makes Redis availability an explicit, recoverable dependency state instead of requiring an application restart.
Validation
pnpm verifygit diff --cached --check