-
Notifications
You must be signed in to change notification settings - Fork 953
[azservicebus] Handle 410 properly for session and non-session based links. #17382
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
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
- For non-sessions links retrying will never work - the lock is lost and can't come back. - For _session_ links it's possible to get the lock after you've lost it since you can basically "recover" the lock by it's name. This comes into play mostly when you lose the lock because of a server-initiated detach. Most of this is just cleaning up the code so I don't have to add yet another argument to the parameters and can just have a simple struct with names, which helps with readability. I've also made it so the function that amqpLinks uses to determine if it should retry is replaceable. To keep the refactor size reasonable I didn't take it this _all_ the way through but it's reasonable as it is now.
Member
Author
|
/azp run go - azservicebus |
|
Azure Pipelines successfully started running 1 pipeline(s). |
seankane-msft
approved these changes
Mar 28, 2022
Contributor
seankane-msft
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
jhendrixMSFT
approved these changes
Mar 28, 2022
Member
jhendrixMSFT
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple nits.
Member
Author
|
/azp run go - azservicebus |
|
Azure Pipelines successfully started running 1 pipeline(s). |
…in favor of using http.Status* constants instead)
Member
Author
|
/azp run go - azservicebus |
|
Azure Pipelines successfully started running 1 pipeline(s). |
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.
410 (lock lost) handling needed to be separated for sessions and non-session links.
For non-session links losing a link is essentially unrecoverable - the lock cannot be reobtained with just the lock token so further retries will always fail.
For session based links it's different since you actually obtain a session lock by opening a link for a particular session ID. You can retry re-opening the link and there are cases where, on detach, that you might have some overlap until the session is actually available again (this is shown in the
TestSessionReceiver_Detachtest).So the split here is simple - all retrying is really handled in amqpLinks, so now it takes a parameter giving it the proper function to determine if an error is fatal or retryable. As part of this I also made the parameters to amqpLinks an arg, which had some small rippling effects in callers.
Fixes #17325
(probable fix for the latest issue mentioned in #17017 since this affects settlement time)