Symptom
A dashboard widget can declare a dataset binding that names nothing — a dataset reference with no corresponding dataset anywhere — and the metadata door takes it without complaint:
Nothing at author time, build time, or publish time notices that the reference resolves to nothing. Referential integrity for this binding is enforced only at runtime, at which point the widget surfaces a visible error in the rendered board.
Recorded as a finding rather than a bug because the runtime failure is honest and loud — the widget does show an error rather than rendering blank or silently empty, which is why the negative clause it sits inside still passed. The gap is the timing: a dangling reference ships all the way to a live board before anyone learns about it.
Root cause
Not root-caused in this run — the observation is behavioural (both the save and the publish arm answer 200). What is established is the shape of the gap: whatever validates a widget's dataset binding at the metadata door does not resolve the reference against the set of datasets that actually exist, so a name that matches nothing is indistinguishable from a name that matches something.
The natural place to look is the metadata validation seam that save and publish share — packages/metadata* — since both arms behave identically, which suggests one shared validator (or one shared absence of one) rather than two independent oversights.
Worth deciding alongside this: whether the reference should be refused at the door, refused only at publish (letting a draft hold a forward reference to a dataset not yet authored), or surfaced as a build-time warning. The "declared = enforced" posture argues for refusing at publish at the latest — a published board with a dangling binding is a broken board with no signal until a user opens it.
Reproduction
- Boot the showcase.
- Author a dashboard widget whose dataset binding names a dataset that does not exist.
- Save the metadata → observe
200. - Publish → observe
200. No error, no warning, no located message on either arm. - Open the board → the widget renders a visible runtime error, confirming the reference is genuinely unresolvable and was never checked earlier.
Source
Extracted from the QA run #7515 (framework a86db17). Recorded there under "Smaller observations".
Symptom
A dashboard widget can declare a dataset binding that names nothing — a dataset reference with no corresponding dataset anywhere — and the metadata door takes it without complaint:
200200Nothing at author time, build time, or publish time notices that the reference resolves to nothing. Referential integrity for this binding is enforced only at runtime, at which point the widget surfaces a visible error in the rendered board.
Recorded as a
findingrather than abugbecause the runtime failure is honest and loud — the widget does show an error rather than rendering blank or silently empty, which is why the negative clause it sits inside still passed. The gap is the timing: a dangling reference ships all the way to a live board before anyone learns about it.Root cause
Not root-caused in this run — the observation is behavioural (both the save and the publish arm answer 200). What is established is the shape of the gap: whatever validates a widget's dataset binding at the metadata door does not resolve the reference against the set of datasets that actually exist, so a name that matches nothing is indistinguishable from a name that matches something.
The natural place to look is the metadata validation seam that save and publish share —
packages/metadata*— since both arms behave identically, which suggests one shared validator (or one shared absence of one) rather than two independent oversights.Worth deciding alongside this: whether the reference should be refused at the door, refused only at publish (letting a draft hold a forward reference to a dataset not yet authored), or surfaced as a build-time warning. The "declared = enforced" posture argues for refusing at publish at the latest — a published board with a dangling binding is a broken board with no signal until a user opens it.
Reproduction
200.200. No error, no warning, no located message on either arm.Source
Extracted from the QA run #7515 (framework a86db17). Recorded there under "Smaller observations".