[
https://issues.apache.org/jira/browse/HBASE-30033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18071737#comment-18071737
]
Hudson commented on HBASE-30033:
--------------------------------
Results for branch branch-2
[build #13 on
builds.a.o|https://ci-hbase.apache.org/job/HBase-Backwards-Compatibility-Test/job/branch-2/13/]:
(x) *{color:red}-1 overall{color}*
----
Backwards compatibility checks:
(/) {color:green}+1 jdk17 hadoop 3.3.5 backward compatibility checks{color}
-- For more information [see jdk17
report|https://ci-hbase.apache.org/job/HBase-Backwards-Compatibility-Test/job/branch-2/13/console]
(/) {color:green}+1 jdk17 hadoop 3.3.6 backward compatibility checks{color}
-- For more information [see jdk17
report|https://ci-hbase.apache.org/job/HBase-Backwards-Compatibility-Test/job/branch-2/13/console]
(x) {color:red}-1 jdk17 hadoop 3.4.0 backward compatibility checks{color}
-- For more information [see jdk17
report|https://ci-hbase.apache.org/job/HBase-Backwards-Compatibility-Test/job/branch-2/13/console]
(/) {color:green}+1 jdk17 hadoop 3.4.1 backward compatibility checks{color}
-- For more information [see jdk17
report|https://ci-hbase.apache.org/job/HBase-Backwards-Compatibility-Test/job/branch-2/13/console]
(/) {color:green}+1 jdk17 hadoop 3.4.2 backward compatibility checks{color}
-- For more information [see jdk17
report|https://ci-hbase.apache.org/job/HBase-Backwards-Compatibility-Test/job/branch-2/13/console]
> Scan.setBatch() validation can be bypassed by calling setBatch() before
> setFilter()
> -----------------------------------------------------------------------------------
>
> Key: HBASE-30033
> URL: https://issues.apache.org/jira/browse/HBASE-30033
> Project: HBase
> Issue Type: Bug
> Components: Client
> Affects Versions: 2.5.11
> Reporter: JeongMin Ju
> Assignee: JeongMin Ju
> Priority: Minor
> Labels: pull-request-available
> Fix For: 2.7.0, 3.0.0-beta-2, 2.5.15, 2.6.6
>
>
> Scan.setBatch(int) validates that the scan does not have a filter with
> hasFilterRow() == true, throwing IncompatibleFilterException if it does.
> However, Scan.setFilter(Filter) does not perform the reverse check against an
> existing batch setting.
> This means calling setBatch() before setFilter() silently creates an
> invalid Scan configuration that setBatch() was designed to prevent:
> {code:java}
> // This correctly throws IncompatibleFilterException
> Scan scan = new Scan();
> scan.setFilter(new PageFilter(10));
> scan.setBatch(5); // throws IncompatibleFilterException
> // This silently creates the same invalid combination
> Scan scan = new Scan();
> scan.setBatch(5); // succeeds - no filter yet
> scan.setFilter(new PageFilter(10)); // succeeds - no batch check
> // scan now has both batch and hasFilterRow()=true filter
> {code}
> When this invalid Scan is executed, setBatch splits rows into partial
> results, but filterRow() operates on partial data instead of the full row,
> producing incorrect results.
> Fix suggestion: Add validation in setFilter(Filter) to check if batch is
> already set:
> {code:java}
> public Scan setFilter(Filter filter) {
> super.setFilter(filter);
> if (this.batch > 0 && filter != null && filter.hasFilterRow()) {
> throw new IncompatibleFilterException(
> "Cannot set a filter that returns true for hasFilterRow on a scan
> with batch set");
> }
> return this;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
