IntervalOpExecSpec uses an unseeded global Random, making failures unreproducible

Inizia con common/workflow-operator/src/test/scala/org/apache/texera/amber/operator/intervalJoin/IntervalOpExecSpec.scala, in particolare con l’importazione e gli utilizzi di Random alle righe 243, 244, 486, 487 e 495. Esegui WorkflowOperator/jacoco due volte come descritto, escludendo FileScanSourceOpExec, e confronta i contatori dei branch di IntervalJoinOpExec.scala. Il lavoro è completato quando la spec mantiene input variati mentre le esecuzioni ripetute producono risultati riproducibili.

What happened?

IntervalOpExecSpec drives its inputs from the global, unseeded scala.util.Random, so its execution path — and therefore its branch coverage — differs from run to run.

import scala.util.Random.{nextInt, nextLong}
...
val leftOrder  = LazyList.continually(nextInt(10)).take(leftInput.length).toList
val rightOrder = LazyList.continually(nextInt(10)).take(rightInput.length).toList
...
val pointList: Array[Long] = LazyList.continually(nextLong()).take(1000).toArray
val rangeList: Array[Long] = LazyList.continually(nextLong()).take(1000).toArray

scala.util.Random used this way is the shared singleton with no seed, so nothing is reproducible.

Two consequences.

The one that is merely annoying: WorkflowOperator's module-wide branch totals are not stable. Two WorkflowOperator/jacoco runs on the same tree, differing only in an unrelated spec, reported IntervalJoinOpExec.scala at 21 and then 22 missed branch arms. That was isolated by diffing every <sourcefile> between the two reports. Anyone quoting module-wide arm counts from a single run can be off by a few, through no fault of their change.

The one that matters more: a genuine failure here may not reproduce. If an ordering or a nextLong() value trips a real bug in the interval-join logic, the run that catches it cannot be replayed, and a re-run will very likely go green.

The fix is small — seed a local generator, e.g. val rng = new scala.util.Random(42) and use rng.nextInt / rng.nextLong — which keeps the input variety while making every run reproducible.

Note the spec filename is IntervalOpExecSpec.scala, not IntervalJoinOpExecSpec.scala, so a search keyed on the class name misses it.

How to reproduce?

1. common/workflow-operator/src/test/scala/org/apache/texera/amber/operator/intervalJoin/IntervalOpExecSpec.scala:31 — the import scala.util.Random.{nextInt, nextLong}, then uses at lines 243, 244, 486, 487 and 495.
2. Run WorkflowOperator/jacoco twice on an unchanged tree, one fresh sbt JVM each, removing common/workflow-operator/target/scala-2.13/jacoco between runs. Compare the <counter type="BRANCH"> figures for IntervalJoinOpExec.scala in the two jacoco.xml reports; they differ between runs.

Exclude FileScanSourceOpExecSpec when doing this — it aborts at suite level on Windows in its own cleanup, and because sbt-jacoco runs unforked and skips saveRuntimeData when the test task fails, an unfiltered run emits an all-zero report rather than a partial one.

Version/Branch

1.3.0-incubating-SNAPSHOT (main)

Was this issue authored using generative AI tooling?

Generated-by: Claude Code (Opus 5)