StdErrorsCanceled

The Canceled error indicates that the operation canceled itself in response to an explicit request to do so. Operations being “canceled” for other reasons (for example the client connection was closed, a time out occured, or due to excessive resource consumption) should not report this error. Examples:

  • A user is monitoring the progress of the operation in a GUI and sees that it is likely to take longer than he is willing to wait and clicks the cancel button.
  • A user invokes the operation using a command-line tool and decides that she didn’t really want to invoke that operation, and presses CTRL-c.

Counterexamples:

  • The client’s connection to the server was closed. Reporting an error is pointless since the client will not receive the error response because the connection has been closed.
  • The request is taking longer than some amount of time. The TimedOut error would be reported if the time was specified as part of the input or is documented in the API contract.

Properties

object
data Optional

Data to facilitate clients responding to the operation reporting a standard error to indicating that it was unable to complete successfully. Operations may provide data that clients can use when responding to errors. Since the data that clients need may be specific to the context of the operation reporting the error, different operations that report the same error may provide different data in the error. The documentation for each each operation will describe what, if any, data it provides for each error it reports. The ArgumentLocations, FileLocations, and TransientIndication structures are intended as possible values for this field. DynamicID may also be useful as a value for this field (although that is not its primary purpose). Some services may provide their own specific structures for use as the value of this field when reporting errors from their operations.

Some operations will not set this field when reporting errors.


error_type Optional

Discriminator field to help API consumers identify the structure type. Can be unset for compatibility with preceding implementations.

Possible values are: ERRORALREADY_EXISTSALREADY_IN_DESIRED_STATECANCELEDCONCURRENT_CHANGEFEATURE_IN_USEINTERNAL_SERVER_ERRORINVALID_ARGUMENTINVALID_ELEMENT_CONFIGURATIONINVALID_ELEMENT_TYPEINVALID_REQUESTNOT_ALLOWED_IN_CURRENT_STATENOT_FOUNDOPERATION_NOT_FOUNDRESOURCE_BUSYRESOURCE_IN_USERESOURCE_INACCESSIBLESERVICE_UNAVAILABLETIMED_OUTUNABLE_TO_ALLOCATE_RESOURCEUNAUTHENTICATEDUNAUTHORIZEDUNEXPECTED_INPUTUNSUPPORTEDUNVERIFIED_PEER


messages Required

Stack of one or more localizable messages for human error consumers. The message at the top of the stack (first in the list) describes the error from the perspective of the operation the client invoked. Each subsequent message in the stack describes the “cause” of the prior message.

JSON Example

{
    "messages": [
        {
            "args": [
                "string"
            ],
            "default_message": "string",
            "id": "string"
        }
    ]
}
Feedback

Was this page helpful?