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 ae0c5e407d722607da8d3aa4578a359e19e59e72 Author: Hongtao Gao <[email protected]> AuthorDate: Thu May 7 22:22:04 2026 +0000 docs(changes): record §6.12 cluster-barrier specs in CHANGES.md Updates the Step 1.0 watch-control entry to mention the three gate locations (handleWatchEvent + processInitialResourceFromProperty + handleDeletion) and adds two new bullets covering: (a) the liaison process binding for setup.PauseDataNodeWatch (via pkg/test/setup.startLiaisonNode + helpers.SharedContext.LiaisonAddr) and (b) §6.12 cluster-barrier integration spec authoring with the pending §6.12a/d disposition explained. via [HAPI](https://hapi.run) Co-Authored-By: HAPI <[email protected]> Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> --- CHANGES.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/CHANGES.md b/CHANGES.md index 847cfb734..4141adca1 100644 --- a/CHANGES.md +++ b/CHANGES.md @@ -44,7 +44,9 @@ Release Notes. - Re-enable §4.6.2 / §4.6.4 / §6.8 / §6.11 in distributed mode (final pass). Distributed schema integration suite reports `Ran 28 of 28 Specs, 0 Skipped`. - Add observability for the schema-consistency cluster (Step 2.7, §A17): `schema_await_revision_applied_duration_seconds{result}`, `schema_await_schema_applied_duration_seconds{result}`, `schema_await_schema_deleted_duration_seconds{result}` track barrier latency by outcome (`applied` / `timeout` / `invalid_argument` / `error`); `schema_barrier_laggard_nodes_total{barrier,role,node}` decodes the `<role>-<Metadata.Name>` laggard identifier so dashboards can break out which member fell b [...] - Add the schema-barrier CP-6 SLO load harness (Step 2.8) under `test/load/schema_barrier/`, runnable via `make load-test-barrier`. The harness brings up an in-process 3 data node + 1 liaison cluster, drives 100 concurrent `AwaitRevisionApplied` callers + 10 `Group.Update` ops/sec, and reports p50 / p95 / p99 / max from client-side per-call duration after a 1-minute warm-up + 5-minute measurement window. Client-side latency is bounded above by the server-side histogram so the SLO check [...] - - Land `pkg/test/setup.PauseDataNodeWatch` / `ResumeDataNodeWatch` (Step 1.0 follow-up): the helpers replace the `ErrWatchControlNotImplemented` stub with a working hook into `property.SchemaRegistry` so cluster-only specs can drive a single data node to fall behind the cluster while the rest stays in sync. The data node's `handleWatchEvent` gates events into a per-registry queue while paused; resume drains the queue in arrival order. This unblocks §6.12a/b/c/d spec authoring without t [...] + - Land `pkg/test/setup.PauseDataNodeWatch` / `ResumeDataNodeWatch` (Step 1.0 follow-up): the helpers replace the `ErrWatchControlNotImplemented` stub with a working hook into `property.SchemaRegistry` so cluster-only specs can drive a single data node to fall behind the cluster while the rest stays in sync. The data node's `handleWatchEvent`, `processInitialResourceFromProperty`, and `handleDeletion` paths each gate events into a per-registry queue while paused; resume drains the queue [...] + - Extend the watch-control binding to liaison processes (`pkg/test/setup.startLiaisonNode`) and add `helpers.SharedContext.LiaisonAddr` so cluster-only specs can pause the receiving liaison's own `SchemaRegistry`. The cluster barrier's `selfName` probe reads through that SR, so pausing it surfaces a laggard via the public `AwaitX` RPCs without needing `NodeSchemaStatusService` exposed on data-node ports — the in-process distributed harness does not currently host that service on data n [...] + - Author §6.12 cluster-barrier integration specs (`test/cases/schema/barrier_cluster.go`): §6.12b (`AwaitSchemaApplied`) and §6.12c (`AwaitSchemaDeleted`) pin the public-API contract that a paused receiving liaison surfaces a non-empty `laggards` list and that resume drains the queue so the per-key barrier converges. §6.12a (`AwaitRevisionApplied`) and §6.12d (cross-barrier recovery) are checked in as `PIt` (pending) — the queue replay runs and the per-key barriers converge, but the gl [...] ### Bug Fixes
