aglinxinyuan opened a new issue, #8150:
URL: https://github.com/apache/texera/issues/8150
### 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.
```scala
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)
--
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]
