Open patrykwoj91 opened 2 months ago
Hello, I am using google-cloud-spanner 6.69.0 for java. I am trying to disable retry mechanism for :
com.google.cloud.spanner.SpannerException: UNAVAILABLE: io.grpc.StatusRuntimeException: UNAVAILABLE: io exception - Statement: 'SELECT 1'
To do that I have followed the documentation, and set:
SpannerOptions.Builder spannerOptionsBuilder = SpannerOptions.newBuilder(); spannerOptionsBuilder.getSpannerStubSettingsBuilder().streamingReadSettings().setRetryableCodes(Collections.emptySet()); spannerOptionsBuilder.getSpannerStubSettingsBuilder().executeStreamingSqlSettings().setRetryableCodes(Collections.emptySet());
However, this doesn't seem to have a valid effect because in the retrying loop: https://github.com/googleapis/java-spanner/blob/6b7e6ca109ea9679b5e36598d3c343fa40bff724/google-cloud-spanner/src/main/java/com/google/cloud/spanner/ResumableStreamIterator.java#L273
method isRetryable is defined as follows:
isRetryable
boolean isRetryable(SpannerException spannerException) { return spannerException.isRetryable() || retryableCodes.contains( GrpcStatusCode.of(spannerException.getErrorCode().getGrpcStatusCode()).getCode()); }
which basically ignores retryableCodes setting, as long as exception itself is marked as retryable.
Not sure if this is a bug or intended behavior, but this still causes the retries to happen, despite setting retryableCodes to empty.
Hello, I am using google-cloud-spanner 6.69.0 for java. I am trying to disable retry mechanism for :
com.google.cloud.spanner.SpannerException: UNAVAILABLE: io.grpc.StatusRuntimeException: UNAVAILABLE: io exception - Statement: 'SELECT 1'
To do that I have followed the documentation, and set:
However, this doesn't seem to have a valid effect because in the retrying loop: https://github.com/googleapis/java-spanner/blob/6b7e6ca109ea9679b5e36598d3c343fa40bff724/google-cloud-spanner/src/main/java/com/google/cloud/spanner/ResumableStreamIterator.java#L273
method
isRetryable
is defined as follows:which basically ignores retryableCodes setting, as long as exception itself is marked as retryable.
Not sure if this is a bug or intended behavior, but this still causes the retries to happen, despite setting retryableCodes to empty.