Namespace Google.Rpc

Classes

BadRequest

Describes violations in a client request. This error type focuses on the syntactic aspects of the request.

BadRequest.Types

Container for nested types declared in the BadRequest message type.

BadRequest.Types.FieldViolation

A message type used to describe a single bad request field.

CodeReflection

Holder for reflection information generated from google/rpc/code.proto

DebugInfo

Describes additional debugging info.

ErrorDetailsReflection

Holder for reflection information generated from google/rpc/error_details.proto

Help

Provides links to documentation or for performing an out of band action.

For example, if a quota check failed with an error indicating the calling project hasn't enabled the accessed service, this can contain a URL pointing directly to the right place in the developer console to flip the bit.

Help.Types

Container for nested types declared in the Help message type.

Help.Types.Link

Describes a URL link.

LocalizedMessage

Provides a localized error message that is safe to return to the user which can be attached to an RPC error.

PreconditionFailure

Describes what preconditions have failed.

For example, if an RPC failed because it required the Terms of Service to be acknowledged, it could list the terms of service violation in the PreconditionFailure message.

PreconditionFailure.Types

Container for nested types declared in the PreconditionFailure message type.

PreconditionFailure.Types.Violation

A message type used to describe a single precondition failure.

QuotaFailure

Describes how a quota check failed.

For example if a daily limit was exceeded for the calling project, a service could respond with a QuotaFailure detail containing the project id and the description of the quota limit that was exceeded. If the calling project hasn't enabled the service in the developer console, then a service could respond with the project id and set service_disabled to true.

Also see RetryDetail and Help types for other details about handling a quota failure.

QuotaFailure.Types

Container for nested types declared in the QuotaFailure message type.

QuotaFailure.Types.Violation

A message type used to describe a single quota violation. For example, a daily quota or a custom quota that was exceeded.

RequestInfo

Contains metadata about the request that clients can attach when filing a bug or providing other forms of feedback.

ResourceInfo

Describes the resource that is being accessed.

RetryInfo

Describes when the clients can retry a failed request. Clients could ignore the recommendation here or retry when this information is missing from error responses.

It's always recommended that clients should use exponential backoff when retrying.

Clients should wait until retry_delay amount of time has passed since receiving the error response before retrying. If retrying requests also fail, clients should use an exponential backoff scheme to gradually increase the delay between retries based on retry_delay, until either a maximum number of retires have been reached or a maximum retry delay cap has been reached.

Status

The Status type defines a logical error model that is suitable for different programming environments, including REST APIs and RPC APIs. It is used by gRPC. The error model is designed to be:

  • Simple to use and understand for most users
  • Flexible enough to meet unexpected needs

Overview

The Status message contains three pieces of data: error code, error message, and error details. The error code should be an enum value of [google.rpc.Code][google.rpc.Code], but it may accept additional error codes if needed. The error message should be a developer-facing English message that helps developers understand and resolve the error. If a localized user-facing error message is needed, put the localized message in the error details or localize it in the client. The optional error details may contain arbitrary information about the error. There is a predefined set of error detail types in the package google.rpc that can be used for common error conditions.

Language mapping

The Status message is the logical representation of the error model, but it is not necessarily the actual wire format. When the Status message is exposed in different client libraries and different wire protocols, it can be mapped differently. For example, it will likely be mapped to some exceptions in Java, but more likely mapped to some error codes in C.

Other uses

The error model and the Status message can be used in a variety of environments, either with or without APIs, to provide a consistent developer experience across different environments.

Example uses of this error model include:

  • Partial errors. If a service needs to return partial errors to the client, it may embed the Status in the normal response to indicate the partial errors.

  • Workflow errors. A typical workflow has multiple steps. Each step may have a Status message for error reporting.

  • Batch operations. If a client uses batch request and batch response, the Status message should be used directly inside batch response, one for each error sub-response.

  • Asynchronous operations. If an API call embeds asynchronous operation results in its response, the status of those operations should be represented directly using the Status message.

  • Logging. If some API errors are stored in logs, the message Status could be used directly after any stripping needed for security/privacy reasons.

StatusReflection

Holder for reflection information generated from google/rpc/status.proto

Enums

Code

The canonical error codes for Google APIs.

Sometimes multiple error codes may apply. Services should return the most specific error code that applies. For example, prefer OUT_OF_RANGE over FAILED_PRECONDITION if both codes apply. Similarly prefer NOT_FOUND or ALREADY_EXISTS over FAILED_PRECONDITION.