Found while producing the boot-path reading for #13331. Filed unassigned; recording only. This is not the #13331 defect and fixing it would not move that card's numbers — it is the observability gap next door.
Two halves
1. "bridged" is logged for a bus that crosses no process boundary
packages/services/service-cluster/src/metadata-cluster-bridge-plugin.ts:61-71 attaches and then logs unconditionally:
MetadataClusterBridgePlugin: bridged metadata.changed → cluster.pubsub (node=${cluster.nodeId})
There is no driver check. Its sibling in the same directory, authz-cluster-bridge-plugin.ts:78-84, does have one, and its comment states the reason in exactly the terms that apply here:
A cluster service IS registered — Runtime registers the memory driver by default — but it fans out to nobody. Reporting this as "bridged" is the exact misreading the posture statement exists to prevent.
isInProcessClusterDriver already exists (./split-brain-guard.js) and is already imported by the authz bridge, so the guard is available; the metadata bridge simply does not ask.
The tree does deliberately hold the two bridges to different bars — the authz bridge's own header says the metadata bridge "may return at debug when no cluster service exists, because a missed metadata.changed costs a stale schema and loses no data". That argument covers silence when absent. It does not cover asserting "bridged" when present-but-in-process, which is a false positive rather than a quiet negative.
2. The plugin has no test file
packages/services/service-cluster/src/
authz-cluster-bridge-plugin.ts
authz-cluster-bridge-plugin.test.ts <-- sibling has one
metadata-cluster-bridge-plugin.ts
(no metadata-cluster-bridge-plugin.test.ts)
Both of the bridge's branches — the attach and the attachClusterPubSub-missing warn — are reachable from a small harness. I exercised both against a real ObjectKernel while reading #13331 and they behave as written (warn with no attach when the slot holds the kernel's memory fallback; attach called once with (pubsub, nodeId) when the slot exposes the method), so the coverage is cheap to add — it just does not exist.
Suggested repair
Adopt the sibling's shape: consult isInProcessClusterDriver(cluster.driver) before claiming bridged, and say the in-process case out loud in the terms the authz bridge already uses. Add the missing test file covering attach / warn / in-process.
Related: #13331 (whose reading surfaced this), #11968 (the ruling that produced the authz bridge's posture statement).
Found while producing the boot-path reading for #13331. Filed unassigned; recording only. This is not the #13331 defect and fixing it would not move that card's numbers — it is the observability gap next door.
Two halves
1. "bridged" is logged for a bus that crosses no process boundary
packages/services/service-cluster/src/metadata-cluster-bridge-plugin.ts:61-71attaches and then logs unconditionally:There is no driver check. Its sibling in the same directory,
authz-cluster-bridge-plugin.ts:78-84, does have one, and its comment states the reason in exactly the terms that apply here:isInProcessClusterDriveralready exists (./split-brain-guard.js) and is already imported by the authz bridge, so the guard is available; the metadata bridge simply does not ask.The tree does deliberately hold the two bridges to different bars — the authz bridge's own header says the metadata bridge "may return at
debugwhen noclusterservice exists, because a missedmetadata.changedcosts a stale schema and loses no data". That argument covers silence when absent. It does not cover asserting "bridged" when present-but-in-process, which is a false positive rather than a quiet negative.2. The plugin has no test file
Both of the bridge's branches — the attach and the
attachClusterPubSub-missing warn — are reachable from a small harness. I exercised both against a realObjectKernelwhile reading #13331 and they behave as written (warn with no attach when the slot holds the kernel's memory fallback; attach called once with(pubsub, nodeId)when the slot exposes the method), so the coverage is cheap to add — it just does not exist.Suggested repair
Adopt the sibling's shape: consult
isInProcessClusterDriver(cluster.driver)before claimingbridged, and say the in-process case out loud in the terms the authz bridge already uses. Add the missing test file covering attach / warn / in-process.Related: #13331 (whose reading surfaced this), #11968 (the ruling that produced the authz bridge's posture statement).