"""
@generated by mypy-protobuf.  Do not edit manually!
isort:skip_file
Copyright 2018 The Bazel Authors.

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
"""
import abc
import buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2
import collections.abc
import buildgrid.common.protos.google.longrunning.operations_pb2
import grpc.aio as grpc
import typing

class ExecutionStub:
    """The Remote Execution API is used to execute an
    [Action][build.bazel.remote.execution.v2.Action] on the remote
    workers.

    As with other services in the Remote Execution API, any call may return an
    error with a [RetryInfo][google.rpc.RetryInfo] error detail providing
    information about when the client should retry the request; clients SHOULD
    respect the information provided.
    """

    def __init__(self, channel: grpc.Channel) -> None: ...
    Execute: grpc.UnaryStreamMultiCallable[
        buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.ExecuteRequest,
        buildgrid.common.protos.google.longrunning.operations_pb2.Operation,
    ]
    """Execute an action remotely.

    In order to execute an action, the client must first upload all of the
    inputs, the
    [Command][build.bazel.remote.execution.v2.Command] to run, and the
    [Action][build.bazel.remote.execution.v2.Action] into the
    [ContentAddressableStorage][build.bazel.remote.execution.v2.ContentAddressableStorage].
    It then calls `Execute` with an `action_digest` referring to them. The
    server will run the action and eventually return the result.

    The input `Action`'s fields MUST meet the various canonicalization
    requirements specified in the documentation for their types so that it has
    the same digest as other logically equivalent `Action`s. The server MAY
    enforce the requirements and return errors if a non-canonical input is
    received. It MAY also proceed without verifying some or all of the
    requirements, such as for performance reasons. If the server does not
    verify the requirement, then it will treat the `Action` as distinct from
    another logically equivalent action if they hash differently.

    Returns a stream of
    [google.longrunning.Operation][google.longrunning.Operation] messages
    describing the resulting execution, with eventual `response`
    [ExecuteResponse][build.bazel.remote.execution.v2.ExecuteResponse]. The
    `metadata` on the operation is of type
    [ExecuteOperationMetadata][build.bazel.remote.execution.v2.ExecuteOperationMetadata].

    If the client remains connected after the first response is returned after
    the server, then updates are streamed as if the client had called
    [WaitExecution][build.bazel.remote.execution.v2.Execution.WaitExecution]
    until the execution completes or the request reaches an error. The
    operation can also be queried using [Operations
    API][google.longrunning.Operations.GetOperation].

    The server NEED NOT implement other methods or functionality of the
    Operations API.

    Errors discovered during creation of the `Operation` will be reported
    as gRPC Status errors, while errors that occurred while running the
    action will be reported in the `status` field of the `ExecuteResponse`. The
    server MUST NOT set the `error` field of the `Operation` proto.
    The possible errors include:

    * `INVALID_ARGUMENT`: One or more arguments are invalid.
    * `FAILED_PRECONDITION`: One or more errors occurred in setting up the
      action requested, such as a missing input or command or no worker being
      available. The client may be able to fix the errors and retry.
    * `RESOURCE_EXHAUSTED`: There is insufficient quota of some resource to run
      the action.
    * `UNAVAILABLE`: Due to a transient condition, such as all workers being
      occupied (and the server does not support a queue), the action could not
      be started. The client should retry.
    * `INTERNAL`: An internal error occurred in the execution engine or the
      worker.
    * `DEADLINE_EXCEEDED`: The execution timed out.
    * `CANCELLED`: The operation was cancelled by the client. This status is
      only possible if the server implements the Operations API CancelOperation
      method, and it was called for the current execution.

    In the case of a missing input or command, the server SHOULD additionally
    send a [PreconditionFailure][google.rpc.PreconditionFailure] error detail
    where, for each requested blob not present in the CAS, there is a
    `Violation` with a `type` of `MISSING` and a `subject` of
    `"blobs/{hash}/{size}"` indicating the digest of the missing blob.

    The server does not need to guarantee that a call to this method leads to
    at most one execution of the action. The server MAY execute the action
    multiple times, potentially in parallel. These redundant executions MAY
    continue to run, even if the operation is completed.
    """
    WaitExecution: grpc.UnaryStreamMultiCallable[
        buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.WaitExecutionRequest,
        buildgrid.common.protos.google.longrunning.operations_pb2.Operation,
    ]
    """Wait for an execution operation to complete. When the client initially
    makes the request, the server immediately responds with the current status
    of the execution. The server will leave the request stream open until the
    operation completes, and then respond with the completed operation. The
    server MAY choose to stream additional updates as execution progresses,
    such as to provide an update as to the state of the execution.
    """

class ExecutionServicer(metaclass=abc.ABCMeta):
    """The Remote Execution API is used to execute an
    [Action][build.bazel.remote.execution.v2.Action] on the remote
    workers.

    As with other services in the Remote Execution API, any call may return an
    error with a [RetryInfo][google.rpc.RetryInfo] error detail providing
    information about when the client should retry the request; clients SHOULD
    respect the information provided.
    """

    @abc.abstractmethod
    async def Execute(
        self,
        request: buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.ExecuteRequest,
        context: grpc.ServicerContext[typing.Any, typing.Any],
    ) -> collections.abc.AsyncIterator[buildgrid.common.protos.google.longrunning.operations_pb2.Operation]:
        """Execute an action remotely.

        In order to execute an action, the client must first upload all of the
        inputs, the
        [Command][build.bazel.remote.execution.v2.Command] to run, and the
        [Action][build.bazel.remote.execution.v2.Action] into the
        [ContentAddressableStorage][build.bazel.remote.execution.v2.ContentAddressableStorage].
        It then calls `Execute` with an `action_digest` referring to them. The
        server will run the action and eventually return the result.

        The input `Action`'s fields MUST meet the various canonicalization
        requirements specified in the documentation for their types so that it has
        the same digest as other logically equivalent `Action`s. The server MAY
        enforce the requirements and return errors if a non-canonical input is
        received. It MAY also proceed without verifying some or all of the
        requirements, such as for performance reasons. If the server does not
        verify the requirement, then it will treat the `Action` as distinct from
        another logically equivalent action if they hash differently.

        Returns a stream of
        [google.longrunning.Operation][google.longrunning.Operation] messages
        describing the resulting execution, with eventual `response`
        [ExecuteResponse][build.bazel.remote.execution.v2.ExecuteResponse]. The
        `metadata` on the operation is of type
        [ExecuteOperationMetadata][build.bazel.remote.execution.v2.ExecuteOperationMetadata].

        If the client remains connected after the first response is returned after
        the server, then updates are streamed as if the client had called
        [WaitExecution][build.bazel.remote.execution.v2.Execution.WaitExecution]
        until the execution completes or the request reaches an error. The
        operation can also be queried using [Operations
        API][google.longrunning.Operations.GetOperation].

        The server NEED NOT implement other methods or functionality of the
        Operations API.

        Errors discovered during creation of the `Operation` will be reported
        as gRPC Status errors, while errors that occurred while running the
        action will be reported in the `status` field of the `ExecuteResponse`. The
        server MUST NOT set the `error` field of the `Operation` proto.
        The possible errors include:

        * `INVALID_ARGUMENT`: One or more arguments are invalid.
        * `FAILED_PRECONDITION`: One or more errors occurred in setting up the
          action requested, such as a missing input or command or no worker being
          available. The client may be able to fix the errors and retry.
        * `RESOURCE_EXHAUSTED`: There is insufficient quota of some resource to run
          the action.
        * `UNAVAILABLE`: Due to a transient condition, such as all workers being
          occupied (and the server does not support a queue), the action could not
          be started. The client should retry.
        * `INTERNAL`: An internal error occurred in the execution engine or the
          worker.
        * `DEADLINE_EXCEEDED`: The execution timed out.
        * `CANCELLED`: The operation was cancelled by the client. This status is
          only possible if the server implements the Operations API CancelOperation
          method, and it was called for the current execution.

        In the case of a missing input or command, the server SHOULD additionally
        send a [PreconditionFailure][google.rpc.PreconditionFailure] error detail
        where, for each requested blob not present in the CAS, there is a
        `Violation` with a `type` of `MISSING` and a `subject` of
        `"blobs/{hash}/{size}"` indicating the digest of the missing blob.

        The server does not need to guarantee that a call to this method leads to
        at most one execution of the action. The server MAY execute the action
        multiple times, potentially in parallel. These redundant executions MAY
        continue to run, even if the operation is completed.
        """
    @abc.abstractmethod
    async def WaitExecution(
        self,
        request: buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.WaitExecutionRequest,
        context: grpc.ServicerContext[typing.Any, typing.Any],
    ) -> collections.abc.AsyncIterator[buildgrid.common.protos.google.longrunning.operations_pb2.Operation]:
        """Wait for an execution operation to complete. When the client initially
        makes the request, the server immediately responds with the current status
        of the execution. The server will leave the request stream open until the
        operation completes, and then respond with the completed operation. The
        server MAY choose to stream additional updates as execution progresses,
        such as to provide an update as to the state of the execution.
        """

def add_ExecutionServicer_to_server(servicer: ExecutionServicer, server: grpc.Server) -> None: ...

class ActionCacheStub:
    """The action cache API is used to query whether a given action has already been
    performed and, if so, retrieve its result. Unlike the
    [ContentAddressableStorage][build.bazel.remote.execution.v2.ContentAddressableStorage],
    which addresses blobs by their own content, the action cache addresses the
    [ActionResult][build.bazel.remote.execution.v2.ActionResult] by a
    digest of the encoded [Action][build.bazel.remote.execution.v2.Action]
    which produced them.

    The lifetime of entries in the action cache is implementation-specific, but
    the server SHOULD assume that more recently used entries are more likely to
    be used again.

    As with other services in the Remote Execution API, any call may return an
    error with a [RetryInfo][google.rpc.RetryInfo] error detail providing
    information about when the client should retry the request; clients SHOULD
    respect the information provided.
    """

    def __init__(self, channel: grpc.Channel) -> None: ...
    GetActionResult: grpc.UnaryUnaryMultiCallable[
        buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.GetActionResultRequest,
        buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.ActionResult,
    ]
    """Retrieve a cached execution result.

    Implementations SHOULD ensure that any blobs referenced from the
    [ContentAddressableStorage][build.bazel.remote.execution.v2.ContentAddressableStorage]
    are available at the time of returning the
    [ActionResult][build.bazel.remote.execution.v2.ActionResult] and will be
    for some period of time afterwards. The lifetimes of the referenced blobs SHOULD be increased
    if necessary and applicable.

    Errors:

    * `NOT_FOUND`: The requested `ActionResult` is not in the cache.
    """
    UpdateActionResult: grpc.UnaryUnaryMultiCallable[
        buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.UpdateActionResultRequest,
        buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.ActionResult,
    ]
    """Upload a new execution result.

    In order to allow the server to perform access control based on the type of
    action, and to assist with client debugging, the client MUST first upload
    the [Action][build.bazel.remote.execution.v2.Execution] that produced the
    result, along with its
    [Command][build.bazel.remote.execution.v2.Command], into the
    `ContentAddressableStorage`.

    Server implementations MAY modify the
    `UpdateActionResultRequest.action_result` and return an equivalent value.

    Errors:

    * `INVALID_ARGUMENT`: One or more arguments are invalid.
    * `FAILED_PRECONDITION`: One or more errors occurred in updating the
      action result, such as a missing command or action.
    * `RESOURCE_EXHAUSTED`: There is insufficient storage space to add the
      entry to the cache.
    """

class ActionCacheServicer(metaclass=abc.ABCMeta):
    """The action cache API is used to query whether a given action has already been
    performed and, if so, retrieve its result. Unlike the
    [ContentAddressableStorage][build.bazel.remote.execution.v2.ContentAddressableStorage],
    which addresses blobs by their own content, the action cache addresses the
    [ActionResult][build.bazel.remote.execution.v2.ActionResult] by a
    digest of the encoded [Action][build.bazel.remote.execution.v2.Action]
    which produced them.

    The lifetime of entries in the action cache is implementation-specific, but
    the server SHOULD assume that more recently used entries are more likely to
    be used again.

    As with other services in the Remote Execution API, any call may return an
    error with a [RetryInfo][google.rpc.RetryInfo] error detail providing
    information about when the client should retry the request; clients SHOULD
    respect the information provided.
    """

    @abc.abstractmethod
    async def GetActionResult(
        self,
        request: buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.GetActionResultRequest,
        context: grpc.ServicerContext[typing.Any, typing.Any],
    ) -> buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.ActionResult:
        """Retrieve a cached execution result.

        Implementations SHOULD ensure that any blobs referenced from the
        [ContentAddressableStorage][build.bazel.remote.execution.v2.ContentAddressableStorage]
        are available at the time of returning the
        [ActionResult][build.bazel.remote.execution.v2.ActionResult] and will be
        for some period of time afterwards. The lifetimes of the referenced blobs SHOULD be increased
        if necessary and applicable.

        Errors:

        * `NOT_FOUND`: The requested `ActionResult` is not in the cache.
        """
    @abc.abstractmethod
    async def UpdateActionResult(
        self,
        request: buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.UpdateActionResultRequest,
        context: grpc.ServicerContext[typing.Any, typing.Any],
    ) -> buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.ActionResult:
        """Upload a new execution result.

        In order to allow the server to perform access control based on the type of
        action, and to assist with client debugging, the client MUST first upload
        the [Action][build.bazel.remote.execution.v2.Execution] that produced the
        result, along with its
        [Command][build.bazel.remote.execution.v2.Command], into the
        `ContentAddressableStorage`.

        Server implementations MAY modify the
        `UpdateActionResultRequest.action_result` and return an equivalent value.

        Errors:

        * `INVALID_ARGUMENT`: One or more arguments are invalid.
        * `FAILED_PRECONDITION`: One or more errors occurred in updating the
          action result, such as a missing command or action.
        * `RESOURCE_EXHAUSTED`: There is insufficient storage space to add the
          entry to the cache.
        """

def add_ActionCacheServicer_to_server(servicer: ActionCacheServicer, server: grpc.Server) -> None: ...

class ContentAddressableStorageStub:
    """The CAS (content-addressable storage) is used to store the inputs to and
    outputs from the execution service. Each piece of content is addressed by the
    digest of its binary data.

    Most of the binary data stored in the CAS is opaque to the execution engine,
    and is only used as a communication medium. In order to build an
    [Action][build.bazel.remote.execution.v2.Action],
    however, the client will need to also upload the
    [Command][build.bazel.remote.execution.v2.Command] and input root
    [Directory][build.bazel.remote.execution.v2.Directory] for the Action.
    The Command and Directory messages must be marshalled to wire format and then
    uploaded under the hash as with any other piece of content. In practice, the
    input root directory is likely to refer to other Directories in its
    hierarchy, which must also each be uploaded on their own.

    For small file uploads the client should group them together and call
    [BatchUpdateBlobs][build.bazel.remote.execution.v2.ContentAddressableStorage.BatchUpdateBlobs].
    For large uploads, the client must use the
    [Write method][google.bytestream.ByteStream.Write] of the ByteStream API. The
    `resource_name` is `{instance_name}/uploads/{uuid}/blobs/{hash}/{size}`,
    where `instance_name` is as described in the next paragraph, `uuid` is a
    version 4 UUID generated by the client, and `hash` and `size` are the
    [Digest][build.bazel.remote.execution.v2.Digest] of the blob. The
    `uuid` is used only to avoid collisions when multiple clients try to upload
    the same file (or the same client tries to upload the file multiple times at
    once on different threads), so the client MAY reuse the `uuid` for uploading
    different blobs. The `resource_name` may optionally have a trailing filename
    (or other metadata) for a client to use if it is storing URLs, as in
    `{instance}/uploads/{uuid}/blobs/{hash}/{size}/foo/bar/baz.cc`. Anything
    after the `size` is ignored.

    A single server MAY support multiple instances of the execution system, each
    with their own workers, storage, cache, etc. The exact relationship between
    instances is up to the server. If the server does, then the `instance_name`
    is an identifier, possibly containing multiple path segments, used to
    distinguish between the various instances on the server, in a manner defined
    by the server. For servers which do not support multiple instances, then the
    `instance_name` is the empty path and the leading slash is omitted, so that
    the `resource_name` becomes `uploads/{uuid}/blobs/{hash}/{size}`.
    To simplify parsing, a path segment cannot equal any of the following
    keywords: `blobs`, `uploads`, `actions`, `actionResults`, `operations` and
    `capabilities`.

    When attempting an upload, if another client has already completed the upload
    (which may occur in the middle of a single upload if another client uploads
    the same blob concurrently), the request will terminate immediately with
    a response whose `committed_size` is the full size of the uploaded file
    (regardless of how much data was transmitted by the client). If the client
    completes the upload but the
    [Digest][build.bazel.remote.execution.v2.Digest] does not match, an
    `INVALID_ARGUMENT` error will be returned. In either case, the client should
    not attempt to retry the upload.

    For downloading blobs, the client must use the
    [Read method][google.bytestream.ByteStream.Read] of the ByteStream API, with
    a `resource_name` of `"{instance_name}/blobs/{hash}/{size}"`, where
    `instance_name` is the instance name (see above), and `hash` and `size` are
    the [Digest][build.bazel.remote.execution.v2.Digest] of the blob.

    The lifetime of entries in the CAS is implementation specific, but it SHOULD
    be long enough to allow for newly-added and recently looked-up entries to be
    used in subsequent calls (e.g. to
    [Execute][build.bazel.remote.execution.v2.Execution.Execute]).

    Servers MUST behave as though empty blobs are always available, even if they
    have not been uploaded. Clients MAY optimize away the uploading or
    downloading of empty blobs.

    As with other services in the Remote Execution API, any call may return an
    error with a [RetryInfo][google.rpc.RetryInfo] error detail providing
    information about when the client should retry the request; clients SHOULD
    respect the information provided.
    """

    def __init__(self, channel: grpc.Channel) -> None: ...
    FindMissingBlobs: grpc.UnaryUnaryMultiCallable[
        buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.FindMissingBlobsRequest,
        buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.FindMissingBlobsResponse,
    ]
    """Determine if blobs are present in the CAS.

    Clients can use this API before uploading blobs to determine which ones are
    already present in the CAS and do not need to be uploaded again.

    Servers SHOULD increase the lifetimes of the referenced blobs if necessary and
    applicable.

    There are no method-specific errors.
    """
    BatchUpdateBlobs: grpc.UnaryUnaryMultiCallable[
        buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.BatchUpdateBlobsRequest,
        buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.BatchUpdateBlobsResponse,
    ]
    """Upload many blobs at once.

    The server may enforce a limit of the combined total size of blobs
    to be uploaded using this API. This limit may be obtained using the
    [Capabilities][build.bazel.remote.execution.v2.Capabilities] API.
    Requests exceeding the limit should either be split into smaller
    chunks or uploaded using the
    [ByteStream API][google.bytestream.ByteStream], as appropriate.

    This request is equivalent to calling a Bytestream `Write` request
    on each individual blob, in parallel. The requests may succeed or fail
    independently.

    Errors:

    * `INVALID_ARGUMENT`: The client attempted to upload more than the
      server supported limit.

    Individual requests may return the following errors, additionally:

    * `RESOURCE_EXHAUSTED`: There is insufficient disk quota to store the blob.
    * `INVALID_ARGUMENT`: The
    [Digest][build.bazel.remote.execution.v2.Digest] does not match the
    provided data.
    """
    BatchReadBlobs: grpc.UnaryUnaryMultiCallable[
        buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.BatchReadBlobsRequest,
        buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.BatchReadBlobsResponse,
    ]
    """Download many blobs at once.

    The server may enforce a limit of the combined total size of blobs
    to be downloaded using this API. This limit may be obtained using the
    [Capabilities][build.bazel.remote.execution.v2.Capabilities] API.
    Requests exceeding the limit should either be split into smaller
    chunks or downloaded using the
    [ByteStream API][google.bytestream.ByteStream], as appropriate.

    This request is equivalent to calling a Bytestream `Read` request
    on each individual blob, in parallel. The requests may succeed or fail
    independently.

    Errors:

    * `INVALID_ARGUMENT`: The client attempted to read more than the
      server supported limit.

    Every error on individual read will be returned in the corresponding digest
    status.
    """
    GetTree: grpc.UnaryStreamMultiCallable[
        buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.GetTreeRequest,
        buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.GetTreeResponse,
    ]
    """Fetch the entire directory tree rooted at a node.

    This request must be targeted at a
    [Directory][build.bazel.remote.execution.v2.Directory] stored in the
    [ContentAddressableStorage][build.bazel.remote.execution.v2.ContentAddressableStorage]
    (CAS). The server will enumerate the `Directory` tree recursively and
    return every node descended from the root.

    The GetTreeRequest.page_token parameter can be used to skip ahead in
    the stream (e.g. when retrying a partially completed and aborted request),
    by setting it to a value taken from GetTreeResponse.next_page_token of the
    last successfully processed GetTreeResponse).

    The exact traversal order is unspecified and, unless retrieving subsequent
    pages from an earlier request, is not guaranteed to be stable across
    multiple invocations of `GetTree`.

    If part of the tree is missing from the CAS, the server will return the
    portion present and omit the rest.

    Errors:

    * `NOT_FOUND`: The requested tree root is not present in the CAS.
    """

class ContentAddressableStorageServicer(metaclass=abc.ABCMeta):
    """The CAS (content-addressable storage) is used to store the inputs to and
    outputs from the execution service. Each piece of content is addressed by the
    digest of its binary data.

    Most of the binary data stored in the CAS is opaque to the execution engine,
    and is only used as a communication medium. In order to build an
    [Action][build.bazel.remote.execution.v2.Action],
    however, the client will need to also upload the
    [Command][build.bazel.remote.execution.v2.Command] and input root
    [Directory][build.bazel.remote.execution.v2.Directory] for the Action.
    The Command and Directory messages must be marshalled to wire format and then
    uploaded under the hash as with any other piece of content. In practice, the
    input root directory is likely to refer to other Directories in its
    hierarchy, which must also each be uploaded on their own.

    For small file uploads the client should group them together and call
    [BatchUpdateBlobs][build.bazel.remote.execution.v2.ContentAddressableStorage.BatchUpdateBlobs].
    For large uploads, the client must use the
    [Write method][google.bytestream.ByteStream.Write] of the ByteStream API. The
    `resource_name` is `{instance_name}/uploads/{uuid}/blobs/{hash}/{size}`,
    where `instance_name` is as described in the next paragraph, `uuid` is a
    version 4 UUID generated by the client, and `hash` and `size` are the
    [Digest][build.bazel.remote.execution.v2.Digest] of the blob. The
    `uuid` is used only to avoid collisions when multiple clients try to upload
    the same file (or the same client tries to upload the file multiple times at
    once on different threads), so the client MAY reuse the `uuid` for uploading
    different blobs. The `resource_name` may optionally have a trailing filename
    (or other metadata) for a client to use if it is storing URLs, as in
    `{instance}/uploads/{uuid}/blobs/{hash}/{size}/foo/bar/baz.cc`. Anything
    after the `size` is ignored.

    A single server MAY support multiple instances of the execution system, each
    with their own workers, storage, cache, etc. The exact relationship between
    instances is up to the server. If the server does, then the `instance_name`
    is an identifier, possibly containing multiple path segments, used to
    distinguish between the various instances on the server, in a manner defined
    by the server. For servers which do not support multiple instances, then the
    `instance_name` is the empty path and the leading slash is omitted, so that
    the `resource_name` becomes `uploads/{uuid}/blobs/{hash}/{size}`.
    To simplify parsing, a path segment cannot equal any of the following
    keywords: `blobs`, `uploads`, `actions`, `actionResults`, `operations` and
    `capabilities`.

    When attempting an upload, if another client has already completed the upload
    (which may occur in the middle of a single upload if another client uploads
    the same blob concurrently), the request will terminate immediately with
    a response whose `committed_size` is the full size of the uploaded file
    (regardless of how much data was transmitted by the client). If the client
    completes the upload but the
    [Digest][build.bazel.remote.execution.v2.Digest] does not match, an
    `INVALID_ARGUMENT` error will be returned. In either case, the client should
    not attempt to retry the upload.

    For downloading blobs, the client must use the
    [Read method][google.bytestream.ByteStream.Read] of the ByteStream API, with
    a `resource_name` of `"{instance_name}/blobs/{hash}/{size}"`, where
    `instance_name` is the instance name (see above), and `hash` and `size` are
    the [Digest][build.bazel.remote.execution.v2.Digest] of the blob.

    The lifetime of entries in the CAS is implementation specific, but it SHOULD
    be long enough to allow for newly-added and recently looked-up entries to be
    used in subsequent calls (e.g. to
    [Execute][build.bazel.remote.execution.v2.Execution.Execute]).

    Servers MUST behave as though empty blobs are always available, even if they
    have not been uploaded. Clients MAY optimize away the uploading or
    downloading of empty blobs.

    As with other services in the Remote Execution API, any call may return an
    error with a [RetryInfo][google.rpc.RetryInfo] error detail providing
    information about when the client should retry the request; clients SHOULD
    respect the information provided.
    """

    @abc.abstractmethod
    async def FindMissingBlobs(
        self,
        request: buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.FindMissingBlobsRequest,
        context: grpc.ServicerContext[typing.Any, typing.Any],
    ) -> buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.FindMissingBlobsResponse:
        """Determine if blobs are present in the CAS.

        Clients can use this API before uploading blobs to determine which ones are
        already present in the CAS and do not need to be uploaded again.

        Servers SHOULD increase the lifetimes of the referenced blobs if necessary and
        applicable.

        There are no method-specific errors.
        """
    @abc.abstractmethod
    async def BatchUpdateBlobs(
        self,
        request: buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.BatchUpdateBlobsRequest,
        context: grpc.ServicerContext[typing.Any, typing.Any],
    ) -> buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.BatchUpdateBlobsResponse:
        """Upload many blobs at once.

        The server may enforce a limit of the combined total size of blobs
        to be uploaded using this API. This limit may be obtained using the
        [Capabilities][build.bazel.remote.execution.v2.Capabilities] API.
        Requests exceeding the limit should either be split into smaller
        chunks or uploaded using the
        [ByteStream API][google.bytestream.ByteStream], as appropriate.

        This request is equivalent to calling a Bytestream `Write` request
        on each individual blob, in parallel. The requests may succeed or fail
        independently.

        Errors:

        * `INVALID_ARGUMENT`: The client attempted to upload more than the
          server supported limit.

        Individual requests may return the following errors, additionally:

        * `RESOURCE_EXHAUSTED`: There is insufficient disk quota to store the blob.
        * `INVALID_ARGUMENT`: The
        [Digest][build.bazel.remote.execution.v2.Digest] does not match the
        provided data.
        """
    @abc.abstractmethod
    async def BatchReadBlobs(
        self,
        request: buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.BatchReadBlobsRequest,
        context: grpc.ServicerContext[typing.Any, typing.Any],
    ) -> buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.BatchReadBlobsResponse:
        """Download many blobs at once.

        The server may enforce a limit of the combined total size of blobs
        to be downloaded using this API. This limit may be obtained using the
        [Capabilities][build.bazel.remote.execution.v2.Capabilities] API.
        Requests exceeding the limit should either be split into smaller
        chunks or downloaded using the
        [ByteStream API][google.bytestream.ByteStream], as appropriate.

        This request is equivalent to calling a Bytestream `Read` request
        on each individual blob, in parallel. The requests may succeed or fail
        independently.

        Errors:

        * `INVALID_ARGUMENT`: The client attempted to read more than the
          server supported limit.

        Every error on individual read will be returned in the corresponding digest
        status.
        """
    @abc.abstractmethod
    async def GetTree(
        self,
        request: buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.GetTreeRequest,
        context: grpc.ServicerContext[typing.Any, typing.Any],
    ) -> collections.abc.AsyncIterator[buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.GetTreeResponse]:
        """Fetch the entire directory tree rooted at a node.

        This request must be targeted at a
        [Directory][build.bazel.remote.execution.v2.Directory] stored in the
        [ContentAddressableStorage][build.bazel.remote.execution.v2.ContentAddressableStorage]
        (CAS). The server will enumerate the `Directory` tree recursively and
        return every node descended from the root.

        The GetTreeRequest.page_token parameter can be used to skip ahead in
        the stream (e.g. when retrying a partially completed and aborted request),
        by setting it to a value taken from GetTreeResponse.next_page_token of the
        last successfully processed GetTreeResponse).

        The exact traversal order is unspecified and, unless retrieving subsequent
        pages from an earlier request, is not guaranteed to be stable across
        multiple invocations of `GetTree`.

        If part of the tree is missing from the CAS, the server will return the
        portion present and omit the rest.

        Errors:

        * `NOT_FOUND`: The requested tree root is not present in the CAS.
        """

def add_ContentAddressableStorageServicer_to_server(servicer: ContentAddressableStorageServicer, server: grpc.Server) -> None: ...

class CapabilitiesStub:
    """The Capabilities service may be used by remote execution clients to query
    various server properties, in order to self-configure or return meaningful
    error messages.

    The query may include a particular `instance_name`, in which case the values
    returned will pertain to that instance.
    """

    def __init__(self, channel: grpc.Channel) -> None: ...
    GetCapabilities: grpc.UnaryUnaryMultiCallable[
        buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.GetCapabilitiesRequest,
        buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.ServerCapabilities,
    ]
    """GetCapabilities returns the server capabilities configuration of the
    remote endpoint.
    Only the capabilities of the services supported by the endpoint will
    be returned:
    * Execution + CAS + Action Cache endpoints should return both
      CacheCapabilities and ExecutionCapabilities.
    * Execution only endpoints should return ExecutionCapabilities.
    * CAS + Action Cache only endpoints should return CacheCapabilities.
    """

class CapabilitiesServicer(metaclass=abc.ABCMeta):
    """The Capabilities service may be used by remote execution clients to query
    various server properties, in order to self-configure or return meaningful
    error messages.

    The query may include a particular `instance_name`, in which case the values
    returned will pertain to that instance.
    """

    @abc.abstractmethod
    async def GetCapabilities(
        self,
        request: buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.GetCapabilitiesRequest,
        context: grpc.ServicerContext[typing.Any, typing.Any],
    ) -> buildgrid.common.protos.build.bazel.remote.execution.v2.remote_execution_pb2.ServerCapabilities:
        """GetCapabilities returns the server capabilities configuration of the
        remote endpoint.
        Only the capabilities of the services supported by the endpoint will
        be returned:
        * Execution + CAS + Action Cache endpoints should return both
          CacheCapabilities and ExecutionCapabilities.
        * Execution only endpoints should return ExecutionCapabilities.
        * CAS + Action Cache only endpoints should return CacheCapabilities.
        """

def add_CapabilitiesServicer_to_server(servicer: CapabilitiesServicer, server: grpc.Server) -> None: ...
