Skip to content
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: retry executeStreamingSql when error code is retryable #795

Merged
merged 3 commits into from
Jan 15, 2020

Conversation

olavloite
Copy link
Contributor

@olavloite olavloite commented Jan 12, 2020

The streaming call executeStreamingSql is not automatically retried by gax, as the gapic configuration for the call does not specify any error codes that should automatically be retried. Instead, the PartialResultStream is responsible for retrying these calls with the appropriate resume token. Until now, the call was only retried when a valid resume token had been seen for the stream, meaning that if the initial call failed with a retryable error code (e.g. UNAVAILABLE), the
stream would fail with this error. This fix ensures that the call is also retried when the error occurs for the initial call or before the stream has returned a valid resume token.

See also

it('should retry UNAVAILABLE from executeStreamingSql with a callback', done => {
for additional tests for retrying streaming errors.

Fixes #620.

@googlebot googlebot added the cla: yes This human has signed the Contributor License Agreement. label Jan 12, 2020
@codecov
Copy link

codecov bot commented Jan 12, 2020

Codecov Report

Merging #795 into master will increase coverage by 0.02%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #795      +/-   ##
==========================================
+ Coverage   74.61%   74.64%   +0.02%     
==========================================
  Files          43       43              
  Lines       20243    20262      +19     
  Branches      547      550       +3     
==========================================
+ Hits        15105    15124      +19     
  Misses       5133     5133              
  Partials        5        5
Impacted Files Coverage Δ
src/partial-result-stream.ts 100% <100%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b1f4ee3...b79920b. Read the comment docs.

Copy link
Contributor

@bcoe bcoe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With my limited knowledge of the spanner library, this seems like a good idea to me 😄 If it could protect our users from temporary outages.

It might be good to discuss this change with @alexander-fenster as well, who has more knowledge of the internal workings of gRPC/gax.

@alexander-fenster
Copy link
Contributor

Just one question: since

as the gapic configuration for the call does not specify any error codes that should automatically be retried

should we talk to API team to reconsider this?

@olavloite
Copy link
Contributor Author

Just one question: since

as the gapic configuration for the call does not specify any error codes that should automatically be retried

should we talk to API team to reconsider this?

That is certainly an option, but it is something that we in that case should do in sync with all client libraries. I know that the Java and Go client libraries also have custom implementations that retry UNAVAILABLE errors for the executeStreamingSql RPC, and I assume that it is also the case of other languages.

The streaming call executeStreamingSql is not automatically retried by gax, as
the gapic configuration for the call does not specify any error codes that should
automatically be retried. Instead, the PartialResultStream is responsible for
retrying these calls with the appropriate resume token. Until now, the call was
only retried when a valid resume token had been seen for the stream, meaning that
if the initial call failed with a retryable error code (e.g. UNAVAILABLE), the
stream would fail with this error. This fix ensures that the call is also retried
when the error occurs for the initial call or before the stream has returned a
valid resume token.

Fixes googleapis#620.
Copy link
Contributor

@hengfengli hengfengli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@olavloite olavloite merged commit 1491858 into googleapis:master Jan 15, 2020
@olavloite olavloite deleted the issue-620 branch January 15, 2020 10:43
AVaksman pushed a commit to AVaksman/nodejs-spanner that referenced this pull request Jan 21, 2020
…is#795)

fix: retry executeStreamingSql when error code is retryable

The streaming call executeStreamingSql is not automatically retried by gax, as the gapic configuration for the call does not specify any error codes that should automatically be retried. Instead, the PartialResultStream is responsible for retrying these calls with the appropriate resume token. Until now, the call was only retried when a valid resume token had been seen for the stream, meaning that if the initial call failed with a retryable error code (e.g. UNAVAILABLE), the stream would fail with this error. This fix ensures that the call is also retried when the error occurs for the initial call or before the stream has returned a valid resume token.

Fixes googleapis#620.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla: yes This human has signed the Contributor License Agreement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

14 UNAVAILABLE: GOAWAY received
5 participants