The GitHub Actions job "Benchmarks PR Comment" on texera.git/main has succeeded. Run started by GitHub user mengw15 (triggered by mengw15).
Head commit for run: 98d3d4b1ec8b02f611801d035c190fa31f56fa47 / Kary Zheng <[email protected]> feat(source): bound a file scan's window at zero (#8514) ### What changes were proposed in this PR? Every file-scan source takes a Limit and an Offset from `ScanSourceOpDesc`, and neither field said it cannot be negative. Both now declare `minimum: 0`. Neither value means anything below zero, and a negative one is not read the same way twice. The executors take the window with Scala's `drop` and `take`, where a negative drop keeps every row and a negative take keeps none. The scripts the export writes take the same window with `iloc`, which counts from the end instead. So `offset = -1` is every row on one side and the last row on the other, and `limit = -1` is no rows on one side and all but the last on the other. Declaring the bound states what the operators already assume, and the property editor then refuses the value rather than passing it on. It reaches CSV, CSVOld, JSONL, Arrow and the file scans at once, all of which inherit the two fields. The schema is not revalidated on the way in, though, so a plan posted to the API or an imported workflow file still arrives with whatever the field holds. Every reader now takes the window through two accessors on the base class, `windowOffset` and `windowLimit`, which clamp at zero. The fields themselves are left as they came, and the native readers behave exactly as they did: `drop(-1)` and `drop(0)` both keep every row, and `take(-1)` and `take(0)` both keep none. What the clamp settles is that a reader counting a negative from the end cannot answer differently from the one that does not. https://github.com/user-attachments/assets/4692ec26-1c93-4ca3-b3e8-d527cd0d0922 ### Any related issues, documentation, discussions? Closes #8513, the task this change is the whole of. ### How was this PR tested? A case in `ScanSourceOpDescSpec` validates `-1`, `0` and `5` against the generated schema for both fields, through the same validator the property editor uses rather than restating the bound the schema declares. Two more deserialize a window through the same polymorphic mapper a saved workflow goes through, and check that a negative reaches the fields intact while the accessors report the empty or the whole window, and that a non-negative one and an absent one pass through untouched. The executor is covered where the value can actually arrive: `CSVScanSourceOpExecSpec` builds the exec from the descriptor's JSON, as a submitted plan does, and runs it over a real file with each negative in turn. A negative limit emits no rows and a negative offset emits all of them. The 166 tests across the scan-source specs pass. The four numbers quoted above were read off the two runtimes rather than from memory: `Iterator(1,2,3,4,5).drop(-1)` keeps all five and `.take(-1)` keeps none, while pandas' `iloc[-1:]` is the last row and `iloc[:-1]` is the first four. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Claude Opus 5) 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 5 (1M context) <[email protected]> Report URL: https://github.com/apache/texera/actions/runs/36680731427 With regards, GitHub Actions via GitBox
