(skywalking-banyandb) branch schema-46-2-skip created (now 0b80fb19e)

[ha...@apache.org]

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

hanahmily pushed a change to branch schema-46-2-skip
in repository https://gitbox.apache.org/repos/asf/skywalking-banyandb.git


      at 0b80fb19e test(schema): defer §4.6.2 to Phase 2 in distributed mode

This branch includes the following new commits:

     new 0b80fb19e test(schema): defer §4.6.2 to Phase 2 in distributed mode

The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails.  The revisions
listed as "add" were already present in the repository and have only
been added to this reference.

(skywalking-banyandb) 01/01: test(schema): defer §4.6.2 to Phase 2 in distributed mode

[ha...@apache.org]

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

hanahmily pushed a commit to branch schema-46-2-skip
in repository https://gitbox.apache.org/repos/asf/skywalking-banyandb.git

commit 0b80fb19ee26997f709e9dff575cd76f23270503
Author: Hongtao Gao <ha...@gmail.com>
AuthorDate: Mon Apr 27 05:18:01 2026 +0000

    test(schema): defer §4.6.2 to Phase 2 in distributed mode
    
    §4.6.2 ("succeeds and returns zero elements when query spans schema
    CreatedAt") is the fourth distributed-mode flake from the same
    Phase-1-vs-Phase-2 cluster-barrier gap.
    
    Unlike §4.6.1 and §4.6.3 — which use End=epoch+1ms so the time-range
    clamp short-circuits at the liaison and never dispatches — §4.6.2 uses
    End=now+1h. The clamped range is non-empty, so the query is dispatched
    to data nodes; in distributed mode the data node may not yet have the
    group registered (Phase 1 AwaitRevisionApplied / AwaitSchemaApplied
    confirm only the liaison's view), causing "group not found" on the
    dispatched query plan.
    
    Cluster-wide barrier semantics ship in Phase 2 via
    NodeSchemaStatusService + liaison fan-out (plan Steps 2.1–2.2);
    re-enable this spec in distributed mode once those land.
    
    via [HAPI](https://hapi.run)
---
 test/cases/schema/clamp.go | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/test/cases/schema/clamp.go b/test/cases/schema/clamp.go
index 12d0ce58e..160c61e74 100644
--- a/test/cases/schema/clamp.go
+++ b/test/cases/schema/clamp.go
@@ -115,6 +115,17 @@ 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() {
+		// TODO(phase-2): Phase 1 AwaitRevisionApplied / AwaitSchemaApplied are liaison-only
+		// by design. Unlike §4.6.1 and §4.6.3 (both ends far in the past, where the clamp
+		// short-circuits at the liaison and never dispatches to data nodes), this spec uses
+		// End=now+1h so the clamped range is non-empty and the query is dispatched. In
+		// distributed mode the data node can lag the liaison's schema view at that moment,
+		// causing the dispatched query to fail with "group not found". Cluster-wide barrier
+		// semantics ship in Phase 2 via NodeSchemaStatusService + liaison fan-out (plan
+		// Steps 2.1–2.2); re-enable this spec in distributed mode once those land.
+		if SharedContext.Mode == "distributed" {
+			g.Skip("§4.6.2 requires cluster-wide propagation barrier (Phase 2)")
+		}
 		groupName := fmt.Sprintf("clamp-span-%d", time.Now().UnixNano())
 		streamName := "clamp_stream"