Retry should not happen when in dedicated connection#6523
Retry should not happen when in dedicated connection#6523harshit-gangal merged 1 commit intovitessio:masterfrom
Conversation
Signed-off-by: Harshit Gangal <harshit@planetscale.com>
sougou
left a comment
There was a problem hiding this comment.
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? |
systay
left a comment
There was a problem hiding this comment.
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