The GitHub Actions job "Required Checks" on texera.git/gh-readonly-queue/main/pr-6980-a61702fd10ccde130f0a24a1298adff24c4a38a5 has failed. Run started by GitHub user aglinxinyuan (triggered by aglinxinyuan).
Head commit for run: 6d038ddefbe96c7055803a588a72031654374f7c / Meng Wang <[email protected]> fix(amber): store execution sizes as BIGINT to stop silent >2GiB truncation (#6980) ### What changes were proposed in this PR? `updateResultSize` / `updateRuntimeStatsSize` / `updateConsoleMessageSize` (`WorkflowExecutionsResource`) stored `Long` byte counts into `INT` columns via `Integer.valueOf(size.toInt)`. Scala's `Long.toInt` keeps only the low 32 bits without raising, so a size ≥ 2 GiB wrapped silently — values in [2 GiB, 4 GiB) became **negative** — and `UserQuotaResource`, which sums `result_size` / `runtime_stats_size` / `console_messages_size` into a user's storage quota, reported corrupted totals. With BigObject (#4067) supporting >2 GB results, such sizes are reachable in practice. - **Widen the three columns to `BIGINT`** in `sql/texera_ddl.sql`, with migration `sql/updates/29.sql` (registered as changelog changeSet 29) for existing deployments — a lossless in-place `ALTER COLUMN ... TYPE BIGINT` for each. - **Store the `Long` directly** at the three write sites, dropping the `.toInt` narrowing (`java.lang.Long.valueOf(size)`; the jOOQ-generated fields become `Long` from the widened schema). - **Adapt the quota reads** in `UserQuotaResource`: the `getOrElse(0).asInstanceOf[Integer]` pattern would throw `ClassCastException` on the now-`Long` fields; simplified to `Option(...).map(_.toLong).getOrElse(0L)`. - **Split the size write out of `updateRuntimeStatsSize` / `updateConsoleMessageSize`** into `(eid, size)` overloads, mirroring the existing `updateResultSize` shape. The outer signatures are unchanged (callers untouched), but the DB write is now reachable without an Iceberg/LakeFS-backed document — so all three writes are directly testable. ### Any related issues, documentation, discussions? Closes #6978. Size columns introduced with the execution result/stats storage; >2 GB results enabled by #4067 (BigObject). ### How was this PR tested? - Added regression cases to `WorkflowExecutionsResourceSpec` (unit spec on embedded Postgres, no external infra): each of the three size writes stores a 3 GiB value and is asserted to round-trip untruncated, plus the two no-URI no-op branches. **Verified the truncation case fails before the fix** — `-1073741824 did not equal 3221225472` (the low-32-bit wrap) — and passes after. - Full spec run locally: 27/27 passed (jOOQ regenerated against the widened schema; the embedded test DB loads the updated `texera_ddl.sql`). - `sql/updates/29.sql` applied cleanly to a local Postgres 15 `texera_db` (three `ALTER TABLE`s in one transaction); columns verified `bigint` afterwards. - `WorkflowExecutionService/scalafmtCheck` (main + Test) passes. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (claude-opus-4-8) --------- Co-authored-by: Yicong Huang <[email protected]> Co-authored-by: Xinyuan Lin <[email protected]> Report URL: https://github.com/apache/texera/actions/runs/30427393133 With regards, GitHub Actions via GitBox
