-
Notifications
You must be signed in to change notification settings - Fork 135
fix: keep track of any BeginTransaction option for a Read #1486
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
fix: keep track of any BeginTransaction option for a Read #1486
Conversation
If a StreamingReadRequest that included a BeginTransaction option was retried as a result of a transient error (UNAVAILABLE), the fact that the BeginTransaction option was included would not be registered for the retried request. This could cause a transaction to fail if the retried request returned an Aborted error, and that Aborted error was caught by the application.
| rpc.read(builder.build(), stream.consumer(), session.getOptions()); | ||
| call.request(prefetchChunks); | ||
| stream.setCall(call, selector != null && selector.hasBegin()); | ||
| stream.setCall(call, /* withBeginTransaction = */ builder.getTransaction().hasBegin()); |
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.
Is this typo? Strange way to write an inline 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.
No, it's not a typo. It's the closest we get to named parameters in Java. We sometimes use it for (boolean) arguments that otherwise are not obvious what they are for.
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.
Thank you for clarification
|
I see integration test failing. |
Seems to be unrelated. I've created a tracking issue and restarted them. |
|
I see it failed again. |
I've increased the timeout in the specific test, and it now succeeds. The test is however completely unrelated to this change, so the test failure rather seems to be related to the backend needing more time than previously to delete a database. |
If a StreamingReadRequest that included a BeginTransaction option was retried as a result
of a transient error (UNAVAILABLE), the fact that the BeginTransaction option was included
would not be registered for the retried request. This could cause a transaction to fail if
the retried request returned an Aborted error, and that Aborted error was caught by the
application.