You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@skywalking.apache.org by "hanahmily (via GitHub)" <gi...@apache.org> on 2026/04/29 19:05:06 UTC
[PR] Phase 2 Step 2.1: NodeSchemaStatusService [skywalking-banyandb]
hanahmily opened a new pull request, #1106:
URL: https://github.com/apache/skywalking-banyandb/pull/1106
## Summary
Step 2.1 of the BanyanDB schema-consistency Phase 2 plan: introduces `NodeSchemaStatusService`, the per-cluster-member RPC that the liaison's distributed barrier fan-out (Steps 2.2 / 2.3 / 2.4) will use to probe every liaison's and every data node's local schema cache.
Phase 1 (#1091, shipped in v0.11.0) made `AwaitRevisionApplied` / `AwaitSchemaApplied` / `AwaitSchemaDeleted` confirm only the **receiving liaison's** cache. This step lays the groundwork for confirming the **whole cluster** — liaisons + data nodes — without touching the existing wire surface.
This PR targets **v0.13.0**. The 0.13.0 milestone does not exist in the repo yet; please set it on this PR if/when it's created.
## Deliverables
- **Cache batch helpers** in `banyand/metadata/schema/property/cache.go`:
- `GetKeyRevisions(propIDs) []KeyRevision` — single-pass batch lookup; same downstream-coherence gate as the existing `GetKeyModRevision`.
- `IsAbsent(propIDs) (absent, present []string)` — partitions a propID list under one read lock.
- **Schema-key conversion** in `banyand/metadata/schema/property/converter.go`:
- `BuildPropertyIDFromSchemaKey(*schemav1.SchemaKey) string` and `kindFromProtoString` translate the proto SchemaKey (underscore_case kind) into the internal propID format.
- **Server implementation** in `banyand/metadata/schema/property/node_status.go`:
- `NodeSchemaStatusServer` implements all three RPCs against a `*SchemaRegistry`.
- The cache it reads is the same `SchemaRegistry` instance the data-node query executor consults via `pkg/schema.schemaRepo` — so a positive answer (`Present=true, rev=R`) implies every downstream cache observed `R`. This satisfies the cache-layer prerequisite called out in the plan for Step 2.5.
- Missing-group semantics: `GetKeyRevisions` returns `mod_revision=0, present=false` (no error) for unknown groups so the liaison can treat group-not-yet-registered as a normal laggard.
- Nil-cache tolerance: an early call before `SchemaRegistry` is initialised returns zero-valued results so the liaison's barrier loop simply retries.
- **Server registration**:
- `banyand/liaison/grpc/server.go` — registered alongside `SchemaBarrierService` so peer liaisons can probe each other.
- `banyand/queue/sub/server.go` — registered on data nodes via the existing `metadataRepo` handle, behind the same nil-check that gates other metadata-dependent services.
## Cross-version compatibility (forward-looking)
During a v0.12 → v0.13 rolling upgrade, a v0.13 liaison may probe a v0.11/v0.12 data node that does not implement `NodeSchemaStatusService`. The data node returns `codes.Unimplemented`. The liaison-side caller in **Step 2.2** (not in this PR) must treat this as "node ready" (`max_revision = ∞`) so partial-upgrade clusters do not deadlock all barrier callers. The server itself is wire-compatible; only the caller needs the policy.
## Tests
`banyand/metadata/schema/property/node_status_test.go`:
- `TestGetMaxRevision_ReflectsLatestApply` — after store at rev=R, RPC returns R
- `TestGetMaxRevision_UnchangedByQuery` — repeated calls read the same snapshot
- `TestGetMaxRevision_NilCache_ReturnsZero` — defensive default
- `TestGetKeyRevisions_PresentAndAbsent` — mixed presence preserves input order
- `TestGetKeyRevisions_UnknownKind_ReportedAbsent` — invalid SchemaKey kind doesn't error
- `TestGetKeyRevisions_NotYetNotified_ReportedAbsent` — entry with `modRevision > notifiedModRevision` reports absent (downstream-coherence regression)
- `TestGetKeyRevisions_ChunkedAtLimit` — 1500-key request, no truncation
- `TestGetKeyRevisions_EmptyRequest_ReturnsEmpty` — empty input handled
- `TestGetAbsentKeys_PostDelete` — partitions correctly across alive / deleted / never-existed keys
- `TestGetAbsentKeys_NilCache_AllAbsent` — defensive default
All 10 new tests pass; no regressions in the existing property / liaison-grpc test suites.
## CI verified locally
- `make license-check && make check-req && make build && make lint && make check` — green
- `make test-ci PKG=./banyand/...` — green
- `make test-ci PKG=./pkg/...` — green
## Out of scope
- **No client-proto sync** — `NodeSchemaStatusService` is internal liaison↔data-node RPC, not part of the OAP-facing surface.
- **No barrier fan-out** — the liaison's per-cluster-member fan-out is Step 2.2.
- **No query-gate work** — Step 2.5 layers the cluster-wide query gate on top of these primitives.
## References
- Phase 1: #1091 (merged in v0.11.0)
- Plan: `.omc/plans/banyandb-schema-tbd-plan.md` §5 Step 2.1 (gitignored; happy to share excerpts)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@skywalking.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Phase 2 Step 2.1: NodeSchemaStatusService [skywalking-banyandb]
Posted by "hanahmily (via GitHub)" <gi...@apache.org>.
hanahmily closed pull request #1106: Phase 2 Step 2.1: NodeSchemaStatusService
URL: https://github.com/apache/skywalking-banyandb/pull/1106
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@skywalking.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org