regenerate APIs

generated/google/apis/genomics_v1/classes.rb

@@ -141,38 +141,38 @@ module Google
         attr_accessor :done
         alias_method :done?, :done
       
-        # The `Status` defines a logical error model that is suitable for different
+        # 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: - Simple to
-        # use and understand for most users. - Flexible enough to meet unexpected needs.
-        # # Overview The `Status` message contains 3 pieces of data: error code, error
+        # 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][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, it can be sent in the error details or localized by
-        # 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` which 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 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 purpose. - 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.
+        # 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` which 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 purpose. - 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.
         # Corresponds to the JSON property `error`
         # @return [Google::Apis::GenomicsV1::Status]
         attr_accessor :error
@@ -200,38 +200,38 @@ module Google
         end
       end
       
-      # The `Status` defines a logical error model that is suitable for different
+      # 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: - Simple to
-      # use and understand for most users. - Flexible enough to meet unexpected needs.
-      # # Overview The `Status` message contains 3 pieces of data: error code, error
+      # 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][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, it can be sent in the error details or localized by
-      # 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` which 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 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 purpose. - 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.
+      # 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` which 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 purpose. - 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.
       class Status
         include Google::Apis::Core::Hashable
       
@@ -2155,7 +2155,10 @@ module Google
         # @return [String]
         attr_accessor :sample_id
       
-        # The IDs of the variant sets this call set belongs to.
+        # The IDs of the variant sets this call set belongs to. This field must have
+        # exactly length one, as a call set belongs to a single variant set. This field
+        # is repeated for compatibility with the [GA4GH 0.5.1 API](https://github.com/
+        # ga4gh/schemas/blob/v0.5.1/src/main/resources/avro/variants.avdl#L76).
         # Corresponds to the JSON property `variantSetIds`
         # @return [Array<String>]
         attr_accessor :variant_set_ids

generated/google/apis/genomics_v1/service.rb

@@ -301,7 +301,7 @@ module Google
         #   The maximum number of results to return. If unspecified, defaults to 256. The
         #   maximum value is 2048.
         # @param [String] page_token
-        #   The standard List page token.
+        #   The standard list page token.
         # @param [String] fields
         #   Selector specifying which fields to include in a partial response.
         # @param [String] quota_user