HyukjinKwon opened a new pull request, #213: URL: https://github.com/apache/spark-connect-rust/pull/213
### What changes were proposed in this pull request? [SPARK-60997](https://issues.apache.org/jira/browse/SPARK-60997): the Rust client now applies the per-RPC deadlines of PySpark Connect 4.3.0's `RpcDeadlines`, and reattaches an execution past the deadline of its stream. - The deadlines: 10 minutes for each stream of a reattachable `ExecutePlan` and each `ReattachExecute`, an hour for `AnalyzePlan` and `AddArtifacts`, and 10 minutes for `Config`, `Interrupt`, `ReleaseSession`, `ArtifactStatus` and `FetchErrorDetails`. A non-reattachable `ExecutePlan` has none, as a timeout would end the execution. The client sends each one as the `grpc-timeout` of its call, and enforces that of an execution's stream while it reads it. - As the reference iterator, when the deadline of an execution's stream passes, the execution goes on on the server, and the client reattaches at once to resume its results. That holds for up to the elapsed time of the reference `RetryException`s, an hour. So does an initial `ExecutePlan` past its deadline. - A `DEADLINE_EXCEEDED` of another call is the `SparkConnectGrpcException` of PySpark's message, which `_handle_rpc_error` raises. - The client's `set_rpc_deadlines` overrides the deadlines, as the `rpc_deadlines` of PySpark's `SparkConnectClient`, and `RpcDeadlines::disabled()` turns them off. ### Why are the changes needed? The client set no deadline, so a call on a connection that broke without an error waited until the connection failed, and an execution's stream could hang forever. ### Does this PR introduce _any_ user-facing change? Yes. Calls have the deadlines of PySpark 4.3.0. An execution's stream that passes its deadline is resumed by reattaching, and another call raises PySpark's error. ### How was this patch tested? - New tests against the mock Connect server of the reattach tests: - An execution whose streams stall reattaches after the deadline of each, and reads its whole result. Each call carries its deadline. - Past the bound of the reattaches, the deadline is the error, and the execution is released. - Disabled deadlines send no timeout. They fail without this change. - A new lib test checks the error of a `DEADLINE_EXCEEDED`. - The lib tests and every integration test, e2e included, against a local Spark 4.3.0 server (664 passed, and 129 of the transport crate), the build of all tests with `wasm-udf`, the offline Python suites (1328 passed, 8 skipped), and the live drop-in and Arrow suites (87 passed) and live cases (10 passed). Clippy reports no diagnostics in the changed lines. ### Was this patch authored or co-authored using generative AI tooling? Generated-by: Claude Opus 5.5 This pull request and its description were written by Isaac. -- 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]
