README
Documentation
¶
Index ¶
- Variables
- func HTTPStatusFromCode(code Code) int
- type BadRequest
- type BadRequestFieldViolation
- type Code
- type DebugInfo
- type Detail
- type Duration
- type Error
- type Help
- type HelpLink
- type LocalizedMessage
- type PreconditionFailure
- type PreconditionFailureViolation
- type QuotaFailure
- type QuotaFailureViolation
- type RequestInfo
- type ResourceInfo
- type RetryInfo
Constants ¶
This section is empty.
Variables ¶
var MarshalJSONWithCode = false
MarshalJSONWithCode show code field when MarshalJSON
Functions ¶
func HTTPStatusFromCode ¶
HTTPStatusFromCode converts a gRPC error code into the corresponding HTTP response status. See: https://github.com/googleapis/googleapis/blob/master/google/rpc/code.proto
Types ¶
type BadRequest ¶
type BadRequest struct {
// Describes all violations in a client request.
FieldViolations []*BadRequestFieldViolation `protobuf:"bytes,1,rep,name=field_violations,json=fieldViolations" json:"field_violations,omitempty"`
}
BadRequest Describes violations in a client request. This error type focuses on the syntactic aspects of the request.
type BadRequestFieldViolation ¶
type BadRequestFieldViolation struct {
// A path leading to a field in the request body. The value will be a
// sequence of dot-separated identifiers that identify a protocol buffer
// field. E.g., "field_violations.field" would identify this field.
Field string `protobuf:"bytes,1,opt,name=field" json:"field,omitempty"`
// A description of why the request element is bad.
Description string `protobuf:"bytes,2,opt,name=description" json:"description,omitempty"`
}
BadRequestFieldViolation A message type used to describe a single bad request field.
type Code ¶
type Code uint32
A Code is an unsigned 32-bit error code as defined in the gRPC spec.
const ( // OK is returned on success. OK Code = 0 // Canceled indicates the operation was canceled (typically by the caller). Canceled Code = 1 // Unknown error. An example of where this error may be returned is // if a Status value received from another address space belongs to // an error-space that is not known in this address space. Also // errors raised by APIs that do not return enough error information // may be converted to this error. Unknown Code = 2 // InvalidArgument indicates client specified an invalid argument. // Note that this differs from FailedPrecondition. It indicates arguments // that are problematic regardless of the state of the system // (e.g., a malformed file name). InvalidArgument Code = 3 // DeadlineExceeded means operation expired before completion. // For operations that change the state of the system, this error may be // returned even if the operation has completed successfully. For // example, a successful response from a server could have been delayed // long enough for the deadline to expire. DeadlineExceeded Code = 4 // NotFound means some requested entity (e.g., file or directory) was // not found. NotFound Code = 5 // AlreadyExists means an attempt to create an entity failed because one // already exists. AlreadyExists Code = 6 // PermissionDenied indicates the caller does not have permission to // execute the specified operation. It must not be used for rejections // caused by exhausting some resource (use ResourceExhausted // instead for those errors). It must not be // used if the caller cannot be identified (use Unauthenticated // instead for those errors). PermissionDenied Code = 7 // ResourceExhausted indicates some resource has been exhausted, perhaps // a per-user quota, or perhaps the entire file system is out of space. ResourceExhausted Code = 8 // FailedPrecondition indicates operation was rejected because the // system is not in a state required for the operation's execution. // For example, directory to be deleted may be non-empty, an rmdir // operation is applied to a non-directory, etc. // // A litmus test that may help a service implementor in deciding // between FailedPrecondition, Aborted, and Unavailable: // (a) Use Unavailable if the client can retry just the failing call. // (b) Use Aborted if the client should retry at a higher-level // (e.g., restarting a read-modify-write sequence). // (c) Use FailedPrecondition if the client should not retry until // the system state has been explicitly fixed. E.g., if an "rmdir" // fails because the directory is non-empty, FailedPrecondition // should be returned since the client should not retry unless // they have first fixed up the directory by deleting files from it. // (d) Use FailedPrecondition if the client performs conditional // REST Get/Update/Delete on a resource and the resource on the // server does not match the condition. E.g., conflicting // read-modify-write on the same resource. FailedPrecondition Code = 9 // Aborted indicates the operation was aborted, typically due to a // concurrency issue like sequencer check failures, transaction aborts, // etc. // // See litmus test above for deciding between FailedPrecondition, // Aborted, and Unavailable. Aborted Code = 10 // OutOfRange means operation was attempted past the valid range. // E.g., seeking or reading past end of file. // // Unlike InvalidArgument, this error indicates a problem that may // be fixed if the system state changes. For example, a 32-bit file // system will generate InvalidArgument if asked to read at an // offset that is not in the range [0,2^32-1], but it will generate // OutOfRange if asked to read from an offset past the current // file size. // // There is a fair bit of overlap between FailedPrecondition and // OutOfRange. We recommend using OutOfRange (the more specific // error) when it applies so that callers who are iterating through // a space can easily look for an OutOfRange error to detect when // they are done. OutOfRange Code = 11 // Unimplemented indicates operation is not implemented or not // supported/enabled in this service. Unimplemented Code = 12 // Internal errors. Means some invariants expected by underlying // system has been broken. If you see one of these errors, // something is very broken. Internal Code = 13 // This is a most likely a transient condition and may be corrected // by retrying with a backoff. // // See litmus test above for deciding between FailedPrecondition, // Aborted, and Unavailable. Unavailable Code = 14 // DataLoss indicates unrecoverable data loss or corruption. DataLoss Code = 15 // Unauthenticated indicates the request does not have valid // authentication credentials for the operation. Unauthenticated Code = 16 )
type DebugInfo ¶
type DebugInfo struct {
// The stack trace entries indicating where the error occurred.
StackEntries []string `protobuf:"bytes,1,rep,name=stack_entries,json=stackEntries" json:"stack_entries,omitempty"`
// Additional debugging information provided by the server.
Detail string `protobuf:"bytes,2,opt,name=detail" json:"detail,omitempty"`
}
DebugInfo Describes additional debugging info.
type Duration ¶
type Duration struct {
// Signed seconds of the span of time. Must be from -315,576,000,000
// to +315,576,000,000 inclusive. Note: these bounds are computed from:
// 60 sec/min * 60 min/hr * 24 hr/day * 365.25 days/year * 10000 years
Seconds int64 `protobuf:"varint,1,opt,name=seconds,proto3" json:"seconds,omitempty"`
// Signed fractions of a second at nanosecond resolution of the span
// of time. Durations less than one second are represented with a 0
// `seconds` field and a positive or negative `nanos` field. For durations
// of one second or more, a non-zero value for the `nanos` field must be
// of the same sign as the `seconds` field. Must be from -999,999,999
// to +999,999,999 inclusive.
Nanos int32 `protobuf:"varint,2,opt,name=nanos,proto3" json:"nanos,omitempty"`
}
Duration A Duration represents a signed, fixed-length span of time represented as a count of seconds and fractions of seconds at nanosecond resolution. It is independent of any calendar and concepts like "day" or "month". It is related to Timestamp in that the difference between two Timestamp values is a Duration and it can be added or subtracted from a Timestamp. Range is approximately +-10,000 years.
Examples ¶
Example 1: Compute Duration from two Timestamps in pseudo code.
Timestamp start = ...;
Timestamp end = ...;
Duration duration = ...;
duration.seconds = end.seconds - start.seconds;
duration.nanos = end.nanos - start.nanos;
if (duration.seconds < 0 && duration.nanos > 0) {
duration.seconds += 1;
duration.nanos -= 1000000000;
} else if (durations.seconds > 0 && duration.nanos < 0) {
duration.seconds -= 1;
duration.nanos += 1000000000;
}
Example 2: Compute Timestamp from Timestamp + Duration in pseudo code.
Timestamp start = ...;
Duration duration = ...;
Timestamp end = ...;
end.seconds = start.seconds + duration.seconds;
end.nanos = start.nanos + duration.nanos;
if (end.nanos < 0) {
end.seconds -= 1;
end.nanos += 1000000000;
} else if (end.nanos >= 1000000000) {
end.seconds += 1;
end.nanos -= 1000000000;
}
Example 3: Compute Duration from datetime.timedelta in Python.
td = datetime.timedelta(days=3, minutes=10) duration = Duration() duration.FromTimedelta(td)
JSON Mapping ¶
In JSON format, the Duration type is encoded as a string rather than an object, where the string ends in the suffix "s" (indicating seconds) and is preceded by the number of seconds, with nanoseconds expressed as fractional seconds. For example, 3 seconds with 0 nanoseconds should be encoded in JSON format as "3s", while 3 seconds and 1 nanosecond should be expressed in JSON format as "3.000000001s", and 3 seconds and 1 microsecond should be expressed in JSON format as "3.000001s".
type Error ¶
type Error struct {
Message string `json:"error,omitempty"`
Code Code `json:"code,omitempty"`
Details []Detail `json:"details,omitempty"`
//compact for simple error
Description string `json:"error_description,omitempty"`
}
Error Default HTTP Error
func (*Error) MarshalJSON ¶
MarshalJSON custom json output
func (*Error) StatusCode ¶
StatusCode return http status code in error
func (*Error) WithDescription ¶
WithDescription add description for error
func (*Error) WithDetails ¶
WithDetails add detail for error
type Help ¶
type Help struct {
// URL(s) pointing to additional information on handling the current error.
Links []*HelpLink `protobuf:"bytes,1,rep,name=links" json:"links,omitempty"`
}
Help Provides links to documentation or for performing an out of band action.
Help 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.
type HelpLink ¶
type HelpLink struct {
// Describes what the link offers.
Description string `protobuf:"bytes,1,opt,name=description" json:"description,omitempty"`
// The URL of the link.
URL string `protobuf:"bytes,2,opt,name=url" json:"url,omitempty"`
}
HelpLink Describes a URL link.
type LocalizedMessage ¶
type LocalizedMessage struct {
// The locale used following the specification defined at
// http://www.rfc-editor.org/rfc/bcp/bcp47.txt.
// Examples are: "en-US", "fr-CH", "es-MX"
Locale string `protobuf:"bytes,1,opt,name=locale" json:"locale,omitempty"`
// The localized error message in the above locale.
Message string `protobuf:"bytes,2,opt,name=message" json:"message,omitempty"`
}
LocalizedMessage Provides a localized error message that is safe to return to the user which can be attached to an RPC error.
type PreconditionFailure ¶
type PreconditionFailure struct {
// Describes all precondition violations.
Violations []*PreconditionFailureViolation `protobuf:"bytes,1,rep,name=violations" json:"violations,omitempty"`
}
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.
type PreconditionFailureViolation ¶
type PreconditionFailureViolation struct {
// The type of PreconditionFailure. We recommend using a service-specific
// enum type to define the supported precondition violation types. For
// example, "TOS" for "Terms of Service violation".
Type string `protobuf:"bytes,1,opt,name=type" json:"type,omitempty"`
// The subject, relative to the type, that failed.
// For example, "google.com/cloud" relative to the "TOS" type would
// indicate which terms of service is being referenced.
Subject string `protobuf:"bytes,2,opt,name=subject" json:"subject,omitempty"`
// A description of how the precondition failed. Developers can use this
// description to understand how to fix the failure.
//
// For example: "Terms of service not accepted".
Description string `protobuf:"bytes,3,opt,name=description" json:"description,omitempty"`
}
PreconditionFailureViolation A message type used to describe a single precondition failure.
type QuotaFailure ¶
type QuotaFailure struct {
// Describes all quota violations.
Violations []*QuotaFailureViolation `protobuf:"bytes,1,rep,name=violations" json:"violations,omitempty"`
}
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.
type QuotaFailureViolation ¶
type QuotaFailureViolation struct {
// The subject on which the quota check failed.
// For example, "clientip:<ip address of client>" or "project:<Google
// developer project id>".
Subject string `protobuf:"bytes,1,opt,name=subject" json:"subject,omitempty"`
// A description of how the quota check failed. Clients can use this
// description to find more about the quota configuration in the service's
// public documentation, or find the relevant quota limit to adjust through
// developer console.
//
// For example: "Service disabled" or "Daily Limit for read operations
// exceeded".
Description string `protobuf:"bytes,2,opt,name=description" json:"description,omitempty"`
}
QuotaFailureViolation A message type used to describe a single quota violation. For example, a daily quota or a custom quota that was exceeded.
type RequestInfo ¶
type RequestInfo struct {
// An opaque string that should only be interpreted by the service generating
// it. For example, it can be used to identify requests in the service's logs.
RequestID string `protobuf:"bytes,1,opt,name=request_id,json=requestId" json:"request_id,omitempty"`
// Any data that was used to serve this request. For example, an encrypted
// stack trace that can be sent back to the service provider for debugging.
ServingData string `protobuf:"bytes,2,opt,name=serving_data,json=servingData" json:"serving_data,omitempty"`
}
RequestInfo Contains metadata about the request that clients can attach when filing a bug or providing other forms of feedback.
type ResourceInfo ¶
type ResourceInfo struct {
// A name for the type of resource being accessed, e.g. "sql table",
// "cloud storage bucket", "file", "Google calendar"; or the type URL
// of the resource: e.g. "type.googleapis.com/google.pubsub.v1.Topic".
ResourceType string `protobuf:"bytes,1,opt,name=resource_type,json=resourceType" json:"resource_type,omitempty"`
// The name of the resource being accessed. For example, a shared calendar
// name: "example.com_4fghdhgsrgh@group.calendar.google.com", if the current
// error is [google.rpc.Code.PERMISSION_DENIED][google.rpc.Code.PERMISSION_DENIED].
ResourceName string `protobuf:"bytes,2,opt,name=resource_name,json=resourceName" json:"resource_name,omitempty"`
// The owner of the resource (optional).
// For example, "user:<owner email>" or "project:<Google developer project
// id>".
Owner string `protobuf:"bytes,3,opt,name=owner" json:"owner,omitempty"`
// Describes what error is encountered when accessing this resource.
// For example, updating a cloud project may require the `writer` permission
// on the developer console project.
Description string `protobuf:"bytes,4,opt,name=description" json:"description,omitempty"`
}
ResourceInfo Describes the resource that is being accessed.
type RetryInfo ¶
type RetryInfo struct {
// Clients should wait at least this long between retrying the same request.
RetryDelay Duration `protobuf:"bytes,1,opt,name=retry_delay,json=retryDelay" json:"retry_delay,omitempty"`
}
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.
Source Files