chore: regenerate synth.metadata (#357)

googleapis · Jan 28, 2020 · 32bf566 · 32bf566
1 parent 00a6e1f
commit 32bf566
Show file tree

Hide file tree

Showing 6 changed files with 561 additions and 270 deletions.
diff --git a/packages/google-cloud-videointelligence/src/v1/doc/google/rpc/doc_status.js b/packages/google-cloud-videointelligence/src/v1/doc/google/rpc/doc_status.js
@@ -18,67 +18,19 @@
 /**
  * The `Status` type defines a logical error model that is suitable for
  * 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).
  *
  * @property {number} code
- *   The status code, which should be an enum value of
- *   google.rpc.Code.
+ *   The status code, which should be an enum value of google.rpc.Code.
  *
  * @property {string} message
  *   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.
+ *   google.rpc.Status.details field, or localized by the client.
  *
  * @property {Object[]} details
  *   A list of messages that carry the error details.  There is a common set of

diff --git a/packages/google-cloud-videointelligence/src/v1beta2/doc/google/rpc/doc_status.js b/packages/google-cloud-videointelligence/src/v1beta2/doc/google/rpc/doc_status.js
@@ -18,67 +18,19 @@
 /**
  * The `Status` type defines a logical error model that is suitable for
  * 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).
  *
  * @property {number} code
- *   The status code, which should be an enum value of
- *   google.rpc.Code.
+ *   The status code, which should be an enum value of google.rpc.Code.
  *
  * @property {string} message
  *   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.
+ *   google.rpc.Status.details field, or localized by the client.
  *
  * @property {Object[]} details
  *   A list of messages that carry the error details.  There is a common set of

diff --git a/packages/google-cloud-videointelligence/src/v1p1beta1/doc/google/rpc/doc_status.js b/packages/google-cloud-videointelligence/src/v1p1beta1/doc/google/rpc/doc_status.js
@@ -18,67 +18,19 @@
 /**
  * The `Status` type defines a logical error model that is suitable for
  * 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).
  *
  * @property {number} code
- *   The status code, which should be an enum value of
- *   google.rpc.Code.
+ *   The status code, which should be an enum value of google.rpc.Code.
  *
  * @property {string} message
  *   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.
+ *   google.rpc.Status.details field, or localized by the client.
  *
  * @property {Object[]} details
  *   A list of messages that carry the error details.  There is a common set of

diff --git a/packages/google-cloud-videointelligence/src/v1p2beta1/doc/google/rpc/doc_status.js b/packages/google-cloud-videointelligence/src/v1p2beta1/doc/google/rpc/doc_status.js
@@ -18,67 +18,19 @@
 /**
  * The `Status` type defines a logical error model that is suitable for
  * 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).
  *
  * @property {number} code
- *   The status code, which should be an enum value of
- *   google.rpc.Code.
+ *   The status code, which should be an enum value of google.rpc.Code.
  *
  * @property {string} message
  *   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.
+ *   google.rpc.Status.details field, or localized by the client.
  *
  * @property {Object[]} details
  *   A list of messages that carry the error details.  There is a common set of

diff --git a/packages/google-cloud-videointelligence/src/v1p3beta1/doc/google/rpc/doc_status.js b/packages/google-cloud-videointelligence/src/v1p3beta1/doc/google/rpc/doc_status.js
@@ -18,67 +18,19 @@
 /**
  * The `Status` type defines a logical error model that is suitable for
  * 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).
  *
  * @property {number} code
- *   The status code, which should be an enum value of
- *   google.rpc.Code.
+ *   The status code, which should be an enum value of google.rpc.Code.
  *
  * @property {string} message
  *   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.
+ *   google.rpc.Status.details field, or localized by the client.
  *
  * @property {Object[]} details
  *   A list of messages that carry the error details.  There is a common set of