Filed by the domain:spec seat at acceptance of PR #13604 (#13405), so the contested observation survives that card's closure. Observation and counter-evidence disagree; neither is discarded here.
The observation (QA, held evidence)
#13405's second-order note, from the QA run #13404 (reproduction withheld per the #9387 disclosure ruling): after datasource DELETE, the admin/detail-door registry cleared but /api/v1/meta/datasource kept serving the deleted entry on all three replicas, prolonging the credential exposure until the entry was scrubbed. The QA reading at the time: "create broadcasts, delete does not mirror."
The counter-evidence (source, PR #13604's dev report on #13405)
At the MetadataManager layer the asymmetry does NOT exist: unregister fans out on CLUSTER_CHANNEL via notifyWatchers, and the receiving peer runs invalidateForForeignWrite — the same fan-out register uses. So the naive mechanism the QA note implies is contradicted; the observed prolongation, which was real, must sit in a different seam.
Candidate seams (named in the dev report, none measured)
What this card is
An observation-vs-source contradiction needing a measurement in a live multi-node deployment, not a fix card yet. The read-side exposure half is already closed by PR #13604 (nested positions now redacted on every read door), so what remains is the lifecycle question: which seam serves a deleted entry, for how long, and is #13578's fix the same fix.
Refs: #13405 (parent finding + dev report with the counter-evidence) · #13578 (open sibling, driver registry) · #5109 (closed, listCache TTL precedent) · #13404 (QA source).
Filed by the domain:spec seat at acceptance of PR #13604 (#13405), so the contested observation survives that card's closure. Observation and counter-evidence disagree; neither is discarded here.
The observation (QA, held evidence)
#13405's second-order note, from the QA run #13404 (reproduction withheld per the #9387 disclosure ruling): after datasource
DELETE, the admin/detail-door registry cleared but/api/v1/meta/datasourcekept serving the deleted entry on all three replicas, prolonging the credential exposure until the entry was scrubbed. The QA reading at the time: "create broadcasts, delete does not mirror."The counter-evidence (source, PR #13604's dev report on #13405)
At the MetadataManager layer the asymmetry does NOT exist:
unregisterfans out onCLUSTER_CHANNELvianotifyWatchers, and the receiving peer runsinvalidateForForeignWrite— the same fan-outregisteruses. So the naive mechanism the QA note implies is contradicted; the observed prolongation, which was real, must sit in a different seam.Candidate seams (named in the dev report, none measured)
restoreRuntimeDatasourcesre-seeding the entry after eviction;listCache/ registry —— 收到广播的节点最长 30s 继续服务旧定义 #5109 measured exactly this shape for cluster peers (up to ~30s), though the QA prolongation reads longer than a TTL;/readykeeps naming it) — if DELETE misses one registry it may miss more than one.What this card is
An observation-vs-source contradiction needing a measurement in a live multi-node deployment, not a fix card yet. The read-side exposure half is already closed by PR #13604 (nested positions now redacted on every read door), so what remains is the lifecycle question: which seam serves a deleted entry, for how long, and is #13578's fix the same fix.
Refs: #13405 (parent finding + dev report with the counter-evidence) · #13578 (open sibling, driver registry) · #5109 (closed, listCache TTL precedent) · #13404 (QA source).