Repository navigation
Document that automatic recovery is not guaranteed after the permanent failure - #4771
Merged
Merged
Conversation
…t failure After JedisPermanentlyNotAvailableException the client may or may not resume on its own. State that clearly, and that user action is required: check the databases and create a new client. Clarify in the failover guide, the exception, MultiDbConfig and MultiDbClient docs what the temporary and permanent phases mean, how maxNumFailoverAttempts and delayInBetweenFailoverAttempts define how long an outage is temporary, and replace the misleading attempts example in the MultiDbConfig Javadoc.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f1b398e73d
ℹ️ 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".
ggivo
added a commit
that referenced
this pull request
Oct 6, 2026
…anteed after the permanent failure (#4776) Document that automatic recovery is not guaranteed after the permanent failure (#4771) After JedisPermanentlyNotAvailableException the client may or may not resume on its own. State that clearly, and that user action is required: check the databases and create a new client. Clarify in the failover guide, the exception, MultiDbConfig and MultiDbClient docs what the temporary and permanent phases mean, how maxNumFailoverAttempts and delayInBetweenFailoverAttempts define how long an outage is temporary, and replace the misleading attempts example in the MultiDbConfig Javadoc. (cherry picked from commit 7e1f878)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #4756 and #4765.
What
Documents that Jedis gives no guarantee of automatic recovery after
JedisPermanentlyNotAvailableException, that user action is required, and that recreating the client is the recommended way to recover.Why
Once the failover attempts are exhausted the client may or may not resume on its own. The docs did not say so, and ended with a paragraph implying that Jedis switches to another database in both the temporary and the permanent case. The
MultiDbConfigJavadocs formaxNumFailoverAttemptsanddelayInBetweenFailoverAttemptsalso described the settings inaccurately ("before giving up", and an attempts example that does not match the code).Changes
docs/failover.md: themaxNumFailoverAttemptsrow, the "When no database is available" section (temporary vs permanent), and a troubleshooting entry forJedisPermanentlyNotAvailableException.JedisPermanentlyNotAvailableExceptionandJedisTemporarilyNotAvailableExceptionJavadocs.MultiDbConfig: Javadocs of the two settings, field and builder.MultiDbClient: class Javadoc.Documentation only, no behavior change, so no release-notes entry.
Note
Low Risk
Documentation and Javadoc only; no production code or behavior changes.
Overview
Documentation-only follow-up that clarifies MultiDb failover behavior when every database is down, with no runtime changes.
docs/failover.mdnow states that automatic recovery is not guaranteed afterJedisPermanentlyNotAvailableException, splits guidance for temporary vs permanent “no healthy database” failures, and adds a troubleshooting section (recreate the client, tunemaxNumFailoverAttempts/delayInBetweenFailoverAttempts). It removes wording that implied Jedis would keep switching databases on its own in both cases.Javadoc is aligned across
MultiDbClient,MultiDbConfig(fields and builder for the two failover-attempt settings), andJedisFailoverExceptionnested types: temporary failures keep auto-retry; permanent failures require operator action and creating a new client is the recommended recovery path. ThemaxNumFailoverAttempts/ delay docs are corrected to describe counted temporary attempts (not misleading “give up” / attempt-count examples).Reviewed by Cursor Bugbot for commit f1b398e. Bugbot is set up for automated code reviews on this repo. Configure here.