Skip to content

branch-4.1: [fix](test) Stabilize test_sql_block_rule_status BLOCKS assertion#65075

Open
CalvinKirs wants to merge 1 commit into
branch-4.1from
4.1-64668
Open

branch-4.1: [fix](test) Stabilize test_sql_block_rule_status BLOCKS assertion#65075
CalvinKirs wants to merge 1 commit into
branch-4.1from
4.1-64668

Conversation

@CalvinKirs

Copy link
Copy Markdown
Member

cherry-pick #64668

…4668)

`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
```

`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.

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]}")
```
@CalvinKirs CalvinKirs requested a review from yiguolei as a code owner July 1, 2026 06:19
@CalvinKirs

Copy link
Copy Markdown
Member Author

run buildall

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant