chore: regens API reference docs (#889)
diff --git a/docs/dyn/bigtableadmin_v2.operations.html b/docs/dyn/bigtableadmin_v2.operations.html
index 6604f0b..0474588 100644
--- a/docs/dyn/bigtableadmin_v2.operations.html
+++ b/docs/dyn/bigtableadmin_v2.operations.html
@@ -171,64 +171,35 @@
{ # This resource represents a long-running operation that is the result of a
# network API call.
+ "response": { # The normal response of the operation in case of success. If the original
+ # method returns no data on success, such as `Delete`, the response is
+ # `google.protobuf.Empty`. If the original method is standard
+ # `Get`/`Create`/`Update`, the response should be the resource. For other
+ # methods, the response should have the type `XxxResponse`, where `Xxx`
+ # is the original method name. For example, if the original method name
+ # is `TakeSnapshot()`, the inferred response type is
+ # `TakeSnapshotResponse`.
+ "a_key": "", # Properties of the object. Contains field @type with type URL.
+ },
"metadata": { # Service-specific metadata associated with the operation. It typically
# contains progress information and common metadata such as create time.
# Some services might not provide such metadata. Any method that returns a
# long-running operation should document the metadata type, if any.
"a_key": "", # Properties of the object. Contains field @type with type URL.
},
+ "done": True or False, # If the value is `false`, it means the operation is still in progress.
+ # If `true`, the operation is completed, and either `error` or `response` is
+ # available.
+ "name": "A String", # The server-assigned name, which is only unique within the same service that
+ # originally returns it. If you use the default HTTP mapping, the
+ # `name` should be a resource name ending with `operations/{unique_id}`.
"error": { # The `Status` type defines a logical error model that is suitable for # The error result of the operation in case of failure or cancellation.
# different programming environments, including REST APIs and RPC APIs. It is
- # used by [gRPC](https://github.com/grpc). The error model is designed to be:
+ # used by [gRPC](https://github.com/grpc). Each `Status` message contains
+ # three pieces of data: error code, error message, and error details.
#
- # - 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, 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.
+ # You can find out more about this error model and how to work with it in the
+ # [API Design Guide](https://cloud.google.com/apis/design/errors).
"message": "A String", # A developer-facing error message, which should be in English. Any
# user-facing error message should be localized and sent in the
# google.rpc.Status.details field, or localized by the client.
@@ -240,22 +211,6 @@
},
],
},
- "done": True or False, # If the value is `false`, it means the operation is still in progress.
- # If `true`, the operation is completed, and either `error` or `response` is
- # available.
- "response": { # The normal response of the operation in case of success. If the original
- # method returns no data on success, such as `Delete`, the response is
- # `google.protobuf.Empty`. If the original method is standard
- # `Get`/`Create`/`Update`, the response should be the resource. For other
- # methods, the response should have the type `XxxResponse`, where `Xxx`
- # is the original method name. For example, if the original method name
- # is `TakeSnapshot()`, the inferred response type is
- # `TakeSnapshotResponse`.
- "a_key": "", # Properties of the object. Contains field @type with type URL.
- },
- "name": "A String", # The server-assigned name, which is only unique within the same service that
- # originally returns it. If you use the default HTTP mapping, the
- # `name` should have the format of `operations/some/unique/name`.
}</pre>
</div>