-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Retry should not happen when in dedicated connection #6523
Retry should not happen when in dedicated connection #6523
Conversation
Signed-off-by: Harshit Gangal <harshit@planetscale.com>
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.
Do you see a use case where this can be a problem? In the case of a transaction, the reason we don't retry is because DMLs are not idempotent. But it may be safe to retry a select
in a reserved connection.
I'm thinking the more correct behavior is that we should disallow retries on anything that's non-idempotent, essentially DMLs, etc.
PS: unit_race has found a race.
Race is unrelated.
|
Currently the retry happens for these two error codes.
I do not see these as transient errors for dedicated connections like transactional connection and reserved connection, because they will hit the same tablet again. |
Could we add a test or two around this logic? |
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, except maybe missing tests
there are discovery gateway tests |
We have checked for transaction ID and blocked any retry in wrapped queryservice. We should also do the same for reserved Connection.
Signed-off-by: Harshit Gangal harshit@planetscale.com