//#region src/apierror/details.d.ts /** * Defines structured error detail types for API errors. * * @packageDocumentation */ /** * ErrorDetails contains the error details of an API error. It is the union of * known error details types and unknown details. */ interface ErrorDetails { 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 parsed into one of * the known types above. */ unknownDetails: unknown[]; } /** ErrorInfo describes the cause of the error with structured details. */ interface ErrorInfo { /** * 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: Record; } /** * RequestInfo contains metadata about the request that clients can attach when * filing a bug or providing other forms of feedback. */ interface RequestInfo { /** * 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; } /** * 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 `retryDelayMs` 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 `retryDelayMs`, until either a maximum * number of retries have been reached or a maximum retry delay cap has been * reached. */ interface RetryInfo { /** Clients should wait at least this long between retrying the same request, in milliseconds. */ retryDelayMs: number; } /** Describes additional debugging info. */ interface DebugInfo { /** The stack trace entries indicating where the error occurred. */ stackEntries: string[]; /** Additional debugging information provided by the server. */ detail: string; } /** * 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. */ interface QuotaFailure { /** Describes all quota violations. */ violations: QuotaFailureViolation[]; } interface QuotaFailureViolation { /** 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; } /** Describes what preconditions have failed. */ interface PreconditionFailure { /** Describes all precondition violations. */ violations: PreconditionFailureViolation[]; } interface PreconditionFailureViolation { /** 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; } /** * Describes violations in a client request. This error type focuses on the * syntactic aspects of the request. */ interface BadRequest { fieldViolations: BadRequestFieldViolation[]; } interface BadRequestFieldViolation { /** A path leading to a field in the request body. */ field: string; /** A description of why the request element is bad. */ description: string; } /** Describes the resource that is being accessed. */ interface ResourceInfo { /** 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; } /** * 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. */ interface Help { /** URL(s) pointing to additional information on handling the current error. */ links: HelpLink[]; } interface HelpLink { /** Describes what the link offers. */ description: string; /** The URL of the link. */ url: string; } /** * Parses an array of raw error detail values into a structured ErrorDetails * object. If multiple details of the same known type are present, the last * one wins. */ declare function parseErrorDetails(rawDetails: unknown[]): ErrorDetails; //#endregion export { BadRequest, BadRequestFieldViolation, DebugInfo, ErrorDetails, ErrorInfo, Help, HelpLink, PreconditionFailure, PreconditionFailureViolation, QuotaFailure, QuotaFailureViolation, RequestInfo, ResourceInfo, RetryInfo, parseErrorDetails }; //# sourceMappingURL=details.d.ts.map