github-actions[bot] commented on code in PR #68455:
URL: https://github.com/apache/doris/pull/68455#discussion_r4089152052
##########
fe/fe-core/src/main/java/org/apache/doris/nereids/trees/expressions/functions/window/WindowFunction.java:
##########
@@ -32,7 +32,7 @@
*/
public abstract class WindowFunction extends BoundFunction implements
SupportWindowAnalytic {
- private static final BigDecimal MAX_BIGINT_OFFSET =
BigDecimal.valueOf(Long.MAX_VALUE);
+ private static final BigDecimal MAX_LEAD_LAG_OFFSET =
BigDecimal.valueOf(Integer.MAX_VALUE);
Review Comment:
[P1] Fix the overflowing ROWS boundary at the shared BE path
This FE-only cap leaves the process crash reachable. A new FE still accepts
`SUM(k) OVER (ORDER BY k ROWS BETWEEN UNBOUNDED PRECEDING AND
9223372036854775807 FOLLOWING)` because the general ROWS check permits
`Long.MAX_VALUE`; BE then evaluates `0 + INT64_MAX + 1` in
`_get_next_for_unbounded_rows`, and a `Long.MAX_VALUE FOLLOWING` start reaches
the sibling unchecked addition. During a rolling upgrade, an old FE can
likewise send the previously accepted LEAD boundary to the unchanged BE. Please
validate every incoming ROWS boundary at the shared BE consumer or make all
start/end/eviction arithmetic overflow-safe while preserving LEAD/LAG
default-row selection, and cover both direct frames and old-FE input.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
