mengw15 opened a new issue, #6978: URL: https://github.com/apache/texera/issues/6978
### What happened? `updateResultSize` / `updateRuntimeStatsSize` / `updateConsoleMessageSize` ([WorkflowExecutionsResource.scala:407/430/455](https://github.com/apache/texera/blob/main/amber/src/main/scala/org/apache/texera/web/resource/dashboard/user/workflow/WorkflowExecutionsResource.scala#L407)) store a `Long` byte count into `INT` columns via `Integer.valueOf(size.toInt)`. The columns `result_size`, `runtime_stats_size`, `console_messages_size` are `INT` (`sql/texera_ddl.sql`). Scala's `Long.toInt` keeps only the low 32 bits with no exception, so a size ≥ 2 GiB wraps — values in [2 GiB, 4 GiB) become **negative**. `UserQuotaResource` ([UserQuotaResource.scala:144/153-156/165](https://github.com/apache/texera/blob/main/amber/src/main/scala/org/apache/texera/web/resource/dashboard/user/quota/UserQuotaResource.scala#L144)) sums these three columns to compute a user's storage quota, so a truncated/negative value corrupts the reported quota. With >2 GB results now supported (BigObject), this is reachable in practice. **Fix:** widen the three columns to `BIGINT` and store the `Long` directly (drop `.toInt`). ### How to reproduce? Materialize an execution result larger than 2 GiB. The stored `result_size` is the low-32-bit truncation of the real byte count (negative for sizes in [2 GiB, 4 GiB)), and the user's quota total in `UserQuotaResource` reflects the wrong value. ### Version 1.1.0-incubating (Pre-release/Master) -- 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]
