Skip to content

[SPARK-56737][SQL] Avoid binary-incompatible mode method on BroadcastExchangeLike#55702

Closed
viirya wants to merge 1 commit intoapache:masterfrom
viirya:refactor-spark-36082
Closed

[SPARK-56737][SQL] Avoid binary-incompatible mode method on BroadcastExchangeLike#55702
viirya wants to merge 1 commit intoapache:masterfrom
viirya:refactor-spark-36082

Conversation

@viirya
Copy link
Copy Markdown
Member

@viirya viirya commented May 6, 2026

What changes were proposed in this pull request?

SPARK-36082 added an abstract def mode: BroadcastMode to the BroadcastExchangeLike trait so that LogicalQueryStageStrategy could distinguish null-aware from regular hashed broadcast stages. Adding an abstract method to a public trait is source- and binary-incompatible for downstream implementations.

Inspect outputPartitioning instead. Every BroadcastExchangeLike must already produce BroadcastPartitioning(mode) to satisfy the BroadcastDistribution(mode) requirement on join sides, so the mode is already exposed through the existing SparkPlan contract and the new abstract method is unnecessary.

Why are the changes needed?

Avoid binary-incompatible mode method on BroadcastExchangeLike.

Does this PR introduce any user-facing change?

No

How was this patch tested?

Exist tests.

Was this patch authored or co-authored using generative AI tooling?

Generated-by: Claude Code

@viirya viirya changed the title SPARK-56737[SQL] Avoid binary-incompatible mode method on BroadcastExchangeLike [SPARK-56737[SQL] Avoid binary-incompatible mode method on BroadcastExchangeLike May 6, 2026
@viirya
Copy link
Copy Markdown
Member Author

viirya commented May 6, 2026

cc @jbharadw-oai @sunchao

@dongjoon-hyun dongjoon-hyun changed the title [SPARK-56737[SQL] Avoid binary-incompatible mode method on BroadcastExchangeLike [SPARK-56737][SQL] Avoid binary-incompatible mode method on BroadcastExchangeLike May 6, 2026
Copy link
Copy Markdown
Member

@dongjoon-hyun dongjoon-hyun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, LGTM.

@dongjoon-hyun
Copy link
Copy Markdown
Member

cc @peter-toth , too.

Follow-up to SPARK-36082. The original change added an abstract
def mode: BroadcastMode to the BroadcastExchangeLike trait so that
LogicalQueryStageStrategy could distinguish null-aware from regular
hashed broadcast stages. Adding an abstract method to a public trait
is source- and binary-incompatible for downstream implementations.

Inspect outputPartitioning instead. Every BroadcastExchangeLike must
already produce BroadcastPartitioning(mode) to satisfy the
BroadcastDistribution(mode) requirement on join sides, so the mode
is already exposed through the existing SparkPlan contract and the
new abstract method is unnecessary.

Co-authored-by: Claude Code
@viirya viirya force-pushed the refactor-spark-36082 branch from c31c15a to b66eb6f Compare May 6, 2026 16:42
@viirya
Copy link
Copy Markdown
Member Author

viirya commented May 6, 2026

Note that, according to #55678 (comment), this needs to be backported to branch-4.x and branch-4.2.

@viirya viirya closed this in de4c521 May 6, 2026
viirya added a commit that referenced this pull request May 6, 2026
…tExchangeLike`

### What changes were proposed in this pull request?

SPARK-36082 added an abstract def mode: BroadcastMode to the BroadcastExchangeLike trait so that LogicalQueryStageStrategy could distinguish null-aware from regular hashed broadcast stages. Adding an abstract method to a public trait is source- and binary-incompatible for downstream implementations.

Inspect outputPartitioning instead. Every BroadcastExchangeLike must already produce BroadcastPartitioning(mode) to satisfy the BroadcastDistribution(mode) requirement on join sides, so the mode is already exposed through the existing SparkPlan contract and the new abstract method is unnecessary.

### Why are the changes needed?

Avoid binary-incompatible mode method on BroadcastExchangeLike.

### Does this PR introduce _any_ user-facing change?

No

### How was this patch tested?

Exist tests.

### Was this patch authored or co-authored using generative AI tooling?

Generated-by: Claude Code

Closes #55702 from viirya/refactor-spark-36082.

Authored-by: Liang-Chi Hsieh <viirya@gmail.com>
Signed-off-by: Liang-Chi Hsieh <viirya@gmail.com>
(cherry picked from commit de4c521)
Signed-off-by: Liang-Chi Hsieh <viirya@gmail.com>
viirya added a commit that referenced this pull request May 6, 2026
…tExchangeLike`

### What changes were proposed in this pull request?

SPARK-36082 added an abstract def mode: BroadcastMode to the BroadcastExchangeLike trait so that LogicalQueryStageStrategy could distinguish null-aware from regular hashed broadcast stages. Adding an abstract method to a public trait is source- and binary-incompatible for downstream implementations.

Inspect outputPartitioning instead. Every BroadcastExchangeLike must already produce BroadcastPartitioning(mode) to satisfy the BroadcastDistribution(mode) requirement on join sides, so the mode is already exposed through the existing SparkPlan contract and the new abstract method is unnecessary.

### Why are the changes needed?

Avoid binary-incompatible mode method on BroadcastExchangeLike.

### Does this PR introduce _any_ user-facing change?

No

### How was this patch tested?

Exist tests.

### Was this patch authored or co-authored using generative AI tooling?

Generated-by: Claude Code

Closes #55702 from viirya/refactor-spark-36082.

Authored-by: Liang-Chi Hsieh <viirya@gmail.com>
Signed-off-by: Liang-Chi Hsieh <viirya@gmail.com>
(cherry picked from commit de4c521)
Signed-off-by: Liang-Chi Hsieh <viirya@gmail.com>
@viirya viirya deleted the refactor-spark-36082 branch May 6, 2026 21:08
@viirya
Copy link
Copy Markdown
Member Author

viirya commented May 6, 2026

Merged to master, branch-4.x, branch-4.2.

Thanks @dongjoon-hyun @sunchao @peter-toth

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants