juliuszsompolski commented on code in PR #42235: URL: https://github.com/apache/spark/pull/42235#discussion_r1281250905
########## python/pyspark/sql/connect/client/reattach.py: ########## @@ -0,0 +1,228 @@ +# +# Licensed to the Apache Software Foundation (ASF) under one or more +# contributor license agreements. See the NOTICE file distributed with +# this work for additional information regarding copyright ownership. +# The ASF licenses this file to You 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. +# +from pyspark.sql.connect.utils import check_dependencies + +check_dependencies(__name__) + +import uuid +from collections.abc import Generator +from typing import Optional, Dict, Any, Iterator +import threading + +import pyspark.sql.connect.proto as pb2 +import pyspark.sql.connect.proto.base_pb2_grpc as grpc_lib + + +class ExecutePlanResponseReattachableIterator(Generator): + """ + Retryable iterator of ExecutePlanResponses to an ExecutePlan call. + + It can handle situations when: + - the ExecutePlanResponse stream was broken by retryable network error (governed by + retryPolicy) + - the ExecutePlanResponse was gracefully ended by the server without a ResultComplete + message; this tells the client that there is more, and it should reattach to continue. + + Initial iterator is the result of an ExecutePlan on the request, but it can be reattached with + ReattachExecute request. ReattachExecute request is provided the responseId of last returned + ExecutePlanResponse on the iterator to return a new iterator from server that continues after + that. + + Since in reattachable execute the server does buffer some responses in case the client needs to + backtrack + """ + + def __init__( + self, + request: pb2.ExecutePlanRequest, + stub: grpc_lib.SparkConnectServiceStub, + retry_policy: Dict[str, Any], + ): + self._request = request + self._retry_policy = retry_policy + if request.operation_id: + self._operation_id = request.operation_id + else: + # Add operation id, if not present. + # with operationId set by the client, the client can use it to try to reattach on error + # even before getting the first response. If the operation in fact didn't even reach the + # server, that will end with INVALID_HANDLE.OPERATION_NOT_FOUND error. + self._operation_id = str(uuid.uuid4()) + + self._stub = stub + request.request_options.append( + pb2.ExecutePlanRequest.RequestOption( + reattach_options=pb2.ReattachOptions(reattachable=True) + ) + ) + self._initial_request = request + + # ResponseId of the last response returned by next() + self._last_returned_response_id: Optional[str] = None + + # True after ResponseComplete message was seen in the stream. + # Server will always send this message at the end of the stream, if the underlying iterator + # finishes without producing one, another iterator needs to be reattached. + self._result_complete = False + + # Initial iterator comes from ExecutePlan request. + self._iterator: Iterator[pb2.ExecutePlanResponse] = self._stub.ExecutePlan( Review Comment: retrying the failure of initial operation starting is tricky, because: - if the initial operation reached the server, retry of ExecutePlan would fail with INVALID_HANDLE.OPERATION_ALREADY_EXISTS; in that case ReattachPlan should be used. And this is what happens here. - but if the initial operation didn't reach the server, then the ReattachPlan will fail with INVALID_HANDLE.OPERATION_NOT_FOUND. This could be improved by making it switch to retrying the ExecutePlan then But I think this is a border case that can be a followup or decided it's not worth it. I believe in the state as is, we will get an INVALID_HANDLE.OPERATION_NOT_FOUND error in case the original ExecutePlan never reached the server. In that case, we could improve it by trying to call ExecutePlan again. But that would have to be caught not here, but during the next() calls. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
