This is an automated email from the ASF dual-hosted git repository. hanahmily pushed a commit to branch phase-2-cp5-march in repository https://gitbox.apache.org/repos/asf/skywalking-banyandb.git
commit 5115385da2712f4b73f678cb4ba6cb5fb86543f8 Author: Hongtao Gao <[email protected]> AuthorDate: Tue May 5 13:59:59 2026 +0000 test(schema): re-skip §4.6.2 in distributed pending Step 2.5 The first-attempt re-enable from 47006561 surfaced a `group not found` race on the second distributed run, matching the existing flake pattern of §6.8 / §6.11 / §4.6.4. Restore the §4.6.2 distributed guard and update the Phase 2 CHANGES.md entry to record that all four specs remain deferred to the cluster query gate (Step 2.5). --- CHANGES.md | 2 +- test/cases/schema/clamp.go | 9 +++++++++ 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/CHANGES.md b/CHANGES.md index b67f064bf..55ad87c34 100644 --- a/CHANGES.md +++ b/CHANGES.md @@ -37,7 +37,7 @@ Release Notes. - `AwaitRevisionApplied` now fans out across the receiving liaison's frozen tier1 (peer-liaison) + tier2 (data-node) Active set, probing each member in parallel via `GetMaxRevision` with shared per-call deadline. Cross-version peers returning `codes.Unimplemented` are treated as ready so partial-upgrade clusters do not deadlock; transient RPC errors count as per-iteration laggards. Empty Active set fails fast with `codes.Unavailable`. - Frozen-snapshot mid-call semantics: members that transition `Active → Evictable` during a call are dropped from subsequent probes and surfaced once as a `NodeLaggard{reason="evicted_during_poll"}`; members that disappear from the route table altogether are dropped silently; late joiners are excluded from the watched set until the next call. Adds `reason` field (5) to `NodeLaggard` proto. - `AwaitSchemaApplied` and `AwaitSchemaDeleted` follow the same fan-out shape using `GetKeyRevisions` / `GetAbsentKeys` respectively, with per-node calls chunked at 1000 keys and a shared call-wide deadline (no equal-slice division across chunks). Per-node laggards carry the per-member `missing_keys` / `still_present_keys` they observed. - - Re-enable §4.6.2 distributed spec (no Write→Query baseline). §6.8, §6.11, §4.6.4 remain skipped pending Step 2.5's cluster query gate. + - First-attempt re-enable of the four Phase-1-deferred distributed specs (§6.8, §6.11, §4.6.4, §4.6.2) confirmed all four still flake under the cluster barrier alone (first run had §4.6.2 passing; second run reproduced the `group not found` race). All four guards stay in place pending Step 2.5's cluster query gate; comments updated to cite the gate as the next prerequisite. ### Bug Fixes diff --git a/test/cases/schema/clamp.go b/test/cases/schema/clamp.go index db21b8717..53def2478 100644 --- a/test/cases/schema/clamp.go +++ b/test/cases/schema/clamp.go @@ -116,6 +116,15 @@ var _ = g.Describe("Schema time-range clamp", func() { // server clamps Begin forward to CreatedAt and the query executes successfully. // Since no data was written the response has zero elements but no error. g.It("succeeds and returns zero elements when query spans schema CreatedAt (§4.6.2)", func() { + // Phase 2.2 cluster barrier converges schema state across nodes, but + // this spec's dispatched query still races the data-node cache update + // in distributed mode (`group not found` returned by the executor). + // First-attempt re-enable in §RE-1 surfaced the flake on the second + // distributed run; restored until Step 2.5's cluster query gate + // removes the residual race. + if SharedContext.Mode == helpers.ModeDistributed { + g.Skip("§4.6.2 requires the cluster-wide query gate (Phase 2 Step 2.5)") + } groupName := fmt.Sprintf("clamp-span-%d", time.Now().UnixNano()) streamName := "clamp_stream"
