This is an automated email from the ASF dual-hosted git repository.

CalvinKirs pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/doris.git


The following commit(s) were added to refs/heads/master by this push:
     new 80b4aa80a23 [fix](test) Stabilize test_sql_block_rule_status BLOCKS 
assertion (#64668)
80b4aa80a23 is described below

commit 80b4aa80a23a2ac897bb9d5956df8d1286369896
Author: Calvin Kirs <[email protected]>
AuthorDate: Tue Jun 23 16:03:54 2026 +0800

    [fix](test) Stabilize test_sql_block_rule_status BLOCKS assertion (#64668)
    
    ## Problem
    
    `test_sql_block_rule_status` fails intermittently on the community P0
    pipeline (observed ~2/8 builds, clustered under high CI load across
    several unrelated PRs). The failure is the exact-value assertion on the
    `BLOCKS` column:
    
    ```
    assertEquals("1", statusRows[0][9].toString())   // expected 1, actual 2
    ```
    
    ## Root cause
    
    `BLOCKS` is read from `SqlBlockRule.getBlockCount()`, a **process-wide,
    monotonically increasing** `LongCounterMetric`. The rule under test is
    created with `global=true`, so its counter is shared cluster-wide and is
    **not isolated** to this test's single matching query.
    
    On a quiet FE a single matching query deterministically yields `BLOCKS
    == 1`, but any additional matching evaluation of the same statement
    under concurrent CI load (e.g. a transient JDBC/network statement
    re-delivery) bumps the shared counter past 1. The defect is the test
    asserting an exact value on a shared monotonic counter — not the
    counting logic itself. This is a pre-existing flake, not introduced by
    any specific PR.
    
    ## Fix
    
    Assert the meaningful invariant — *the rule fired at least once* —
    instead of an exact, racy count:
    
    ```groovy
    assertTrue(Integer.parseInt(statusRows[0][9].toString()) >= 1,
            "BLOCKS should be >= 1 but was ${statusRows[0][9]}")
    ```
---
 .../suites/query_p0/schema_table/test_sql_block_rule_status.groovy | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git 
a/regression-test/suites/query_p0/schema_table/test_sql_block_rule_status.groovy
 
b/regression-test/suites/query_p0/schema_table/test_sql_block_rule_status.groovy
index f7eb9970628..1a71f02c6ef 100644
--- 
a/regression-test/suites/query_p0/schema_table/test_sql_block_rule_status.groovy
+++ 
b/regression-test/suites/query_p0/schema_table/test_sql_block_rule_status.groovy
@@ -63,7 +63,12 @@ suite("test_sql_block_rule_status") {
     assertEquals(1, statusRows.size())
     assertEquals(blockRuleName, statusRows[0][0].toString())
     assertEquals("false", statusRows[0][8].toString())
-    assertEquals("1", statusRows[0][9].toString())
+    // BLOCKS is a process-wide, monotonically increasing hit counter on a 
global block rule.
+    // It is not isolated to this test's single query, so any extra matching 
evaluation under
+    // concurrent CI load (e.g. a transient statement re-delivery) can bump it 
past 1. Assert the
+    // meaningful invariant "the rule fired at least once" instead of an 
exact, racy count.
+    assertTrue(Integer.parseInt(statusRows[0][9].toString()) >= 1,
+            "BLOCKS should be >= 1 but was ${statusRows[0][9]}")
      sql """
         drop SQL_BLOCK_RULE if exists ${blockRuleName};
     """


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to