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.

Sign up for GitHub

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

Jump to bottom

Retry RESOURCE_EXHAUSTED only if the server can recover #2480

Merged
merged 5 commits into from
Apr 13, 2022
Merged

Retry RESOURCE_EXHAUSTED only if the server can recover #2480

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
40ff9f0
Retry RESOURCE_EXHAUSTED only if the server can recover
svrakitin Apr 8, 2022
e8f1fa4
specify implementation details
svrakitin Apr 8, 2022
f1bc9be
Use wording from a PR comment
svrakitin Apr 8, 2022
28a5e8a
Merge branch 'main' into resource-exhausted-recovery
svrakitin Apr 12, 2022
3540d47
Merge branch 'main' into resource-exhausted-recovery
reyang Apr 13, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,6 +24,7 @@ release.
### OpenTelemetry Protocol

- Clarify gRPC insecure option ([#2476](https://github.com/open-telemetry/opentelemetry-specification/pull/2476))
- Specify that OTLP/gRPC clients should retry on `RESOURCE_EXHAUSTED` code only if the server signals backpressure to indicate a possible recovery. ([#2480](https://github.com/open-telemetry/opentelemetry-specification/pull/2480))

### SDK Configuration

Expand Down
7 changes: 6 additions & 1 deletion specification/protocol/otlp.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -223,7 +223,7 @@ not-retryable according to the following table:
|ALREADY_EXISTS|No|
|PERMISSION_DENIED|No|
|UNAUTHENTICATED|No|
|RESOURCE_EXHAUSTED|Yes|
|RESOURCE_EXHAUSTED|Only if the server can recover (see below)|
|FAILED_PRECONDITION|No|
|ABORTED|Yes|
|OUT_OF_RANGE|Yes|
Expand All @@ -236,6 +236,11 @@ When retrying, the client SHOULD implement an exponential backoff strategy. An
exception to this is the Throttling case explained below, which provides
explicit instructions about retrying interval.

The client SHOULD interpret `RESOURCE_EXHAUSTED` code as retryable only if the server signals that the recovery from resource exhaustion is possible. This is signalled by the server by returning [a status](https://godoc.org/google.golang.org/grpc/status#Status.WithDetails)
containing
[RetryInfo](https://github.com/googleapis/googleapis/blob/6a8c7914d1b79bd832b5157a09a9332e8cbd16d4/google/rpc/error_details.proto#L40). In this case the behavior of the server and the client is exactly as described in [OTLP/gRPC Throttling](#otlpgrpc-throttling) section.
If no such status is returned then the `RESOURCE_EXHAUSTED` code SHOULD be treated as non-retryable.

#### OTLP/gRPC Throttling

OTLP allows backpressure signalling.
Expand Down