Ma77Ball opened a new pull request, #5032:
URL: https://github.com/apache/texera/pull/5032
### What changes were proposed in this PR?
`LinkConfig.toPartitioning`'s `BroadcastPartition()` arm was building
channels with `fromWorkerIds.zip(toWorkerIds)`, producing a 1:1 pairing rather
than the full sender-by-receiver cross product that broadcast semantics imply.
The sibling `ChannelConfig.generateChannelConfigs` in the same package
already emits a cross product for the broadcast arm, so the two helpers
disagreed on routing for the same inputs. As with #4799 for `OneToOnePartition`,
`List.zip` also silently truncated the surplus side on unequal-length
inputs. This PR replaces the `zip` with the same `flatMap` / `map` cross
product already used by the `HashPartition`, `RangePartition`, and
`UnknownPartition` arms in this file, which fixes the semantics and
removes the silent truncation hazard.
### Any related issues, documentation, or discussions?
Closes: #4802
### How was this PR tested?
The two `LinkConfigSpec` cases that pinned the previous behavior (with
comments explicitly inviting this realignment) were flipped to assert the cross
product: 3 senders by 3 receivers now produces 9 channels, and the
Asymmetric 3 by 2 case now produces 6 channels rather than silently
truncating to 2. `sbt scalafmtAll` was run; CI should pass the existing
`LinkConfigSpec`, `ChannelConfigSpec`, and downstream scheduling specs.
### Was this PR authored or co-authored using generative AI tooling?
Co-authored with Claude Opus 4.7 in compliance with ASF
--
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]
