The GitHub Actions job "Required Checks" on texera.git/backport/6907-fall-back-to-day-semantics-for-an-unset-v1.2 has succeeded. Run started by GitHub user Yicong-Huang (triggered by Yicong-Huang).
Head commit for run: 8ce45feced7324d532de8016f057fafc8d1466a4 / Meng Wang <[email protected]> fix(workflow-operator): fall back to day semantics for an unset interval type; extend aggregate and interval-join tests (#6907) ### What changes were proposed in this PR? Writing the coverage tests asked for in #6901 turned up a live defect in `IntervalJoinOpExec`, so this fixes that and adds the tests around it. **An unset `timeIntervalType` crashed the timestamp branch instead of falling back to days.** `IntervalJoinOpDesc` declares `var timeIntervalType: Option[TimeIntervalType] = _`, and an absent JSON field deserializes to `Some(null)` — not `None`, and not `null`. The match in `intervalCompare` only handled `Some(<each unit>)` and `None`, so any TIMESTAMP interval join whose descriptor omits the field died with `scala.MatchError: Some(null)` rather than taking the documented day fallback. Replaced `case None` with a catch-all, which also covers `None` and any unit added later. This makes the fallback arm reachable for the first time; it was dead code before. On the coverage side, `AggregationOperationSpec` gains the accepting half of the SUM/MIN/MAX type guard — the four-clause `!= INTEGER && != DOUBLE && != LONG && != TIMESTAMP` chain was only ever driven with INTEGER/DOUBLE and the rejecting types, so its later clauses were never walked — plus AVERAGE over a TIMESTAMP column, which is the only route into the `parseTimestamp(...).getTime` branch of `getNumericalValue` (AVERAGE is otherwise only exercised over DOUBLE). Two items from the issue are deliberately **not** included, because they are already covered on `main`: the `TimeIntervalType` ladder and the `processNumValue` bound-combination arms were covered by #6098 (`"join timestamps across every interval unit"` plus the four `[] [) (] ()` tests), and `newAggFunc`'s non-COUNT arm is covered by the existing SUM `getFinal` pipeline test. `AveragePartialObj` is likewise already constructed by an existing test. The `maxAgg` finaliser asymmetry the issue mentions is left alone — it is a behavior change in live code and deserves its own PR. ### Any related issues, documentation, discussions? Closes #6901. ### How was this PR tested? Both touched specs pass (27 tests), and the full `WorkflowOperator/test` suite passes with 1957 tests and no regressions; `scalafmtCheck` and `scalafix --check` are clean. The new interval-join test is the regression test for the fix: reverting the catch-all back to `case None` reddens it with the original `scala.MatchError: Some(null)`, which is how the defect was found in the first place. ### Was this PR authored or co-authored using generative AI tooling? (backported from commit 03a0e3a3b12424b99fa829d56fdb0a7512c6f173) Generated-by: Claude Code (Fable 5) Report URL: https://github.com/apache/texera/actions/runs/30422498163 With regards, GitHub Actions via GitBox
