Repository navigation
Conversation
…o numeric aliases
…nd iterator failure semantics
…ns and tighten lifecycle coverage
… completion records per operation
…e readiness counter
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this pull request?
Preserve PySpark 4.3.0's timing for
spark.sql.execution.pyspark.binaryAsBytes: eager actions read it after execution;toLocalIterator()snapshots it on the firstnext(), before execution. Apply it to Arrow-only results too.Configuration or converter-initialization errors now terminate the iterator and release any incomplete execution. Closing an iterator also wakes prefetch while it waits for another response, allowing prompt execution release.
Why are the changes needed?
SPARK-61099, following initial binary support in #320. Reading configuration after the first fetch can consume a row before an error and allow later calls to resume. Schema-dependent configuration checks also miss Arrow-only results.
Includes the NumPy prerequisite, tracked by SPARK-61102.
Does this PR introduce any user-facing change?
Yes. Eager/lazy configuration timing and failed-iterator cleanup match PySpark. Direct binary map keys retain PySpark's
TypeErrorwhen bytearray keys are unhashable. Binary-backed UDT map-key behavior remains outside this patch.How was this patch tested?
The shared full and cluster runs executed the NumPy prerequisite binary. This branch has the same 43 selected raw-RPC source files and separate native-import/live validation. This is source-based reuse of transport evidence; those full and cluster runs did not execute this branch's binary. They use official Python plans and converters, with no per-child import attestation, and do not validate native high-level conversion, native ReleaseSession or native artifact upload.
The full run completed 87 normal files: 2,586 passed, 641 skipped, one deselected and no failures, errors or retries. Eleven files were entirely skipped. A separate advisory check of the existing metadata-column manifest entry still failed because the test catalog plugin was unavailable (one failure, 57 deselections). The cluster phase passed 15 invocations across four modules (ten substantive cases and five helpers), with 14 JVM-guarded skips and no failures or retries.
The original full run had a seeded-random failure on two threads. The unchanged test failed identically in official Python and both saved Rust transports on two threads, and passed in all three on its default four-thread fixture. The complete successful rerun used that fixture. Server logs retain deliberate negative-test diagnostics and shutdown races; successful direct shutdown was recorded, without final descendant-process telemetry.
Clippy remains advisory exit 101; its source diagnostics were assessed against the baseline. Linux, Windows and the newest-master combined tree were not runtime tested locally.
Was this patch authored or co-authored using generative AI tooling?
Generated-by: OpenAI Codex
This pull request and its description were written by OpenAI Codex.