This repository was archived by the owner on Feb 18, 2025. It is now read-only.
LeaderURI: self identify, avoid infinite forwarding #792
Conversation
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
Closed
|
@shlomi-noach Thanks a billion for being on this so quickly. I'll test the fix first thing today. |
|
Hi Shlomi, apologies, took me a while to set up our custom orchestrator build, but I now have the docker image with your patch backported onto |
|
Thanks for the update. If all goes well I'll merge it this week. |
|
@shlomi-noach just deployed it in production, looks great! Thanks again for the speedy fix! |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
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.
Fixes #696
In #696, a demoted leader tries to reverse proxy HTTP requests to the leader, but the
LeaderURIit has is its own, which leads to infinite reverse-proxy to itself.In this PR:
The change of behavior is:
Instead of an infinite loop, the host will attempt to serve the request. This isn't ideal either: the node is not the leader, but can't figure out who the leader is (yet). A client that attempts to run an operation during this time will get a "read only" error.
Thank you to @mia0x75 @makmanalp for illustrating the problem. Can you please test this PR?