What
SecurityPlugin.getObjectSecurityMeta resolves an object's posture with:
let obj = this.ql?.getSchema(object);
if (!obj) { try { obj = await this.metadata?.get?.('object', object); } catch { obj = null; } }
…
unresolved: !obj
IMetadataService.get is documented as ambiguous by construction — its own TSDoc
(packages/spec/src/contracts/metadata-service.ts:305) says undefined means "not found"
and "every loader that could hold it failed", and directs callers to getDiagnosed
(#5840) "wherever the difference could change a decision". getDiagnosed returns a
degraded verdict alongside the data; MetadataManager already computes it and get
discards it.
Here the difference does change something: a metadata-store outage and a
genuinely absent declaration collapse into one unresolved: true and, since #10401,
into one message — "neither the live schema nor the metadata service returned a
declaration for it … Check that the object is declared and published on this runtime."
That advice is correct for an absent object and misleading during an outage, where the
remedy is to look at the store, not at the declaration. Same defect class as #10401, one
input over.
Not an access question
The deny is right either way and must stay fail-closed (#3545) — a degraded read
must never resolve to a grant. This is about the explanation and the log line only,
exactly like #10401: unresolvedCause (added by #10401, security-plugin.ts) already
carries an explanation-only discriminator with a 'unknown' fail-safe default, so a
third cause ('metadata_unavailable') would slot into the existing
unresolved-posture.ts wording module rather than needing new plumbing.
Why it is filed rather than fixed in #10401
#10401's scope is the unpublished-draft/unresolvable split. This is a different input
(the read's own trustworthiness), it needs the optional getDiagnosed? capability probed
and a fallback for services that do not implement it, and the "outage" wording deserves
its own review. Filed unassigned.
Where
Found while implementing #10401 (PR #10423).
What
SecurityPlugin.getObjectSecurityMetaresolves an object's posture with:IMetadataService.getis documented as ambiguous by construction — its own TSDoc(
packages/spec/src/contracts/metadata-service.ts:305) saysundefinedmeans "not found"and "every loader that could hold it failed", and directs callers to
getDiagnosed(#5840) "wherever the difference could change a decision".
getDiagnosedreturns adegradedverdict alongside the data;MetadataManageralready computes it andgetdiscards it.
Here the difference does change something: a metadata-store outage and a
genuinely absent declaration collapse into one
unresolved: trueand, since #10401,into one message — "neither the live schema nor the metadata service returned a
declaration for it … Check that the object is declared and published on this runtime."
That advice is correct for an absent object and misleading during an outage, where the
remedy is to look at the store, not at the declaration. Same defect class as #10401, one
input over.
Not an access question
The deny is right either way and must stay fail-closed (#3545) — a degraded read
must never resolve to a grant. This is about the explanation and the log line only,
exactly like #10401:
unresolvedCause(added by #10401,security-plugin.ts) alreadycarries an explanation-only discriminator with a
'unknown'fail-safe default, so athird cause (
'metadata_unavailable') would slot into the existingunresolved-posture.tswording module rather than needing new plumbing.Why it is filed rather than fixed in #10401
#10401's scope is the unpublished-draft/unresolvable split. This is a different input
(the read's own trustworthiness), it needs the optional
getDiagnosed?capability probedand a fallback for services that do not implement it, and the "outage" wording deserves
its own review. Filed unassigned.
Where
packages/plugins/plugin-security/src/security-plugin.ts—getObjectSecurityMeta,the
metadata.getcall andunresolved: !objpackages/plugins/plugin-security/src/unresolved-posture.ts— where a third causewould be worded
packages/spec/src/contracts/metadata-service.ts—getvsgetDiagnosed(MetadataManager.get() 丢弃 loadDiagnosed 的 degraded 判定:loader 读不到与「这一项没声明」在 6 个消费点上不可分辨 #5840)Found while implementing #10401 (PR #10423).