hutiefang76 opened a new issue, #4412: URL: https://github.com/apache/amoro/issues/4412
### What happened? TableController reads page and pageSize without consistent positive-value or offset validation across ten endpoints. Invalid parameters can reach backend work, wrap the int offset, or return HTTP 500. Expected: HTTP 400 before backend pagination for invalid input. Defaults remain page=1 and pageSize=20, and valid integer boundaries remain accepted. ### Affects Versions master at 061eb724e93592fe87cf44b61af34c1d799f5db6 ### What table formats are you seeing the problem on? _No response_ ### What engines are you seeing the problem on? _No response_ ### How to reproduce 1. Send a table pagination request, for example the optimizing-process tasks endpoint, with page=0 or pageSize=0. 2. Repeat with a negative parameter or page=2147483647 and pageSize=2, whose offset exceeds Integer.MAX_VALUE. 3. Invalid input can reach downstream work, wrap the offset, or produce HTTP 500 instead of a validation response. The minimal regression fixture uses actual Javalin query validators and four HTTP requests through embedded Javalin with the real validation and generic exception handlers. ### Relevant log output ```shell ``` ### Anything else 108 regression cases cover all ten endpoints. The base has 64 failures, including HTTP 500 instead of 400. The fix makes all 108 pass; the existing 19 optimizer-pagination tests also pass. The 15-module reactor compiles and Spotless/Checkstyle validation passes. The tested branch is hutiefang76/amoro fix/table-pagination-validation. ### Are you willing to submit a PR? - [x] Yes I am willing to submit a PR! ### Code of Conduct - [x] I agree to follow this project's Code of Conduct -- 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]
