What happened?
amber/src/main/scala/org/apache/texera/amber/engine/architecture/scheduling/config/ChannelConfig.scala::ChannelConfig.generateChannelConfigs uses fromWorkerIds.zip(toWorkerIds) for the OneToOnePartition arm. Scala's List.zip truncates to the shorter side, so calling this method with mismatched-length worker lists silently drops the surplus pairings instead of raising. The other partitioning arms either compute a full cross product or assert exact-length expectations (SinglePartition requires toWorkerIds.size == 1); only OneToOne has this silent-truncation hazard.
How to reproduce?
import org.apache.texera.amber.core.virtualidentity.ActorVirtualIdentity
import org.apache.texera.amber.core.workflow.{OneToOnePartition, PortIdentity}
import org.apache.texera.amber.engine.architecture.scheduling.config.ChannelConfig
val w = (1 to 3).map(i => ActorVirtualIdentity(s"w$i")).toList
val u = (1 to 2).map(i => ActorVirtualIdentity(s"u$i")).toList
val out = ChannelConfig.generateChannelConfigs(w, u, PortIdentity(0, false), OneToOnePartition())
// out.size == 2 — w3 silently has no channel even though OneToOne implies a 1:1 contract
Version
1.1.0-incubating (Pre-release/Master)
What happened?
amber/src/main/scala/org/apache/texera/amber/engine/architecture/scheduling/config/ChannelConfig.scala::ChannelConfig.generateChannelConfigsusesfromWorkerIds.zip(toWorkerIds)for theOneToOnePartitionarm. Scala'sList.ziptruncates to the shorter side, so calling this method with mismatched-length worker lists silently drops the surplus pairings instead of raising. The other partitioning arms either compute a full cross product or assert exact-length expectations (SinglePartitionrequirestoWorkerIds.size == 1); onlyOneToOnehas this silent-truncation hazard.How to reproduce?
Version
1.1.0-incubating (Pre-release/Master)