Documentation
¶
Index ¶
- func Code(err error) codes.Code
- type APIError
- func (e *APIError) Code() codes.Code
- func (e *APIError) Details() ErrorDetails
- func (e *APIError) Error() string
- func (e *APIError) HTTPBody() []byte
- func (e *APIError) HTTPHeader() http.Header
- func (e *APIError) HTTPStatusCode() int
- func (e *APIError) Message() string
- func (e *APIError) Unwrap() error
- type BadRequest
- type BadRequestFieldViolation
- type DebugInfo
- type ErrorDetails
- type ErrorInfo
- type Help
- type HelpLink
- type PreconditionFailure
- type PreconditionFailureViolation
- type QuotaFailure
- type QuotaFailureViolation
- type RequestInfo
- type ResourceInfo
- type RetryInfo
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
Types ¶
type APIError ¶
type APIError struct {
// contains filtered or unexported fields
}
APIError is a transport-agnostic error representing a Databricks API error.
func FromHTTPError ¶
FromHTTPError parses an HTTP error response into an APIError; it returns nil if the status code is 2xx or 3xx.
func (*APIError) Details ¶
func (e *APIError) Details() ErrorDetails
Details returns the APIError's error details.
func (*APIError) HTTPBody ¶
HTTPBody returns the APIError's HTTP body. If the APIError is not an HTTP error, it returns nil.
func (*APIError) HTTPHeader ¶
HTTPHeader returns the APIError's HTTP headers. If the APIError is not an HTTP error, it returns nil.
func (*APIError) HTTPStatusCode ¶
HTTPStatusCode returns the APIError's HTTP status code. If the APIError is not an HTTP error, it returns -1.
type BadRequest ¶
type BadRequest struct {
FieldViolations []BadRequestFieldViolation
}
Describes violations in a client request. This error type focuses on the syntactic aspects of the request.
type DebugInfo ¶
type DebugInfo struct {
// The stack trace entries indicating where the error occurred.
StackEntries []string
// Additional debugging information provided by the server.
Detail string
}
Describes additional debugging info.
type ErrorDetails ¶
type ErrorDetails struct {
ErrorInfo *ErrorInfo
RequestInfo *RequestInfo
RetryInfo *RetryInfo
DebugInfo *DebugInfo
QuotaFailure *QuotaFailure
PreconditionFailure *PreconditionFailure
BadRequest *BadRequest
ResourceInfo *ResourceInfo
Help *Help
// UnknownDetails contains error details that cannot be unmarshalled into
// one of the known types above.
UnknownDetails []any
}
ErrorDetails contains the error details of an API error. It is the union of known error details types and unknown details.
type ErrorInfo ¶
type ErrorInfo struct {
// The reason of the error. This is a constant value that identifies the
// proximate cause of the error.
Reason string
// The logical grouping to which the "reason" belongs.
Domain string
// Additional structured details about this error.
Metadata map[string]string
}
ErrorInfo describes the cause of the error with structured details.
type Help ¶
type Help struct {
// URL(s) pointing to additional information on handling the current error.
Links []HelpLink
}
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.
type PreconditionFailure ¶
type PreconditionFailure struct {
// Describes all precondition violations.
Violations []PreconditionFailureViolation
}
Describes what preconditions have failed.
type PreconditionFailureViolation ¶
type PreconditionFailureViolation struct {
// The type of PreconditionFailure.
Type string
// The subject, relative to the type, that failed.
Subject string
// 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
}
type QuotaFailure ¶
type QuotaFailure struct {
// Describes all quota violations.
Violations []QuotaFailureViolation
}
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 RetryInfo and Help types for other details about handling a quota failure.
type QuotaFailureViolation ¶
type QuotaFailureViolation struct {
// The subject on which the quota check failed.
Subject string
// 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
}
type RequestInfo ¶
type RequestInfo struct {
// An opaque string that should only be interpreted by the service that
// generated it. For example, it can be used to identify requests in the
// service's logs.
RequestID string
// 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
}
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.
ResourceType string
// The name of the resource being accessed.
ResourceName string
// The owner of the resource (optional).
Owner string
// Describes what error is encountered when accessing this resource.
Description string
}
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 time.Duration
}
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 retries have been reached or a maximum retry delay cap has been reached.