A node type that fails to build does not fail the request
One unbuildable node type costs the reader that node's metadata, not the whole response.
The rule
- Where a node type cannot be built from its own declaration or stored data, the failure is contained: the request being served still succeeds, the node is returned unenriched (SCH-25), and the failure is recorded where an operator can find it.
- This governs failures attributable to the node type.
- Behaviour when an implementation's own extension code violates the contract it was written against is outside this specification, which describes conforming implementations and not malfunctioning ones.
What it means
A node type that cannot be built does not take the whole response down with it: the caller still gets an answer, and the one node whose type failed comes back exactly as it was stored, carrying none of the metadata a successful build would have added — not even an empty one. This holds only for failures the node type's own declaration or stored data is responsible for. A failure inside an implementation's own extension code that breaks the contract it was written against is a different case the specification does not describe, because describing conforming behaviour is not the same as guaranteeing something useful once the implementation itself is broken.
Example
{
"id": "n1",
"type": "legacyType",
"position": { "x": 1, "y": 2 },
"data": {
"metadata": { "node_type_id": "broken" },
"config": { "instanceTitle": "Kept" }
}
}{ "node_type_id": "broken" }Nothing else about the request fails: the node keeps the metadata it already had, and the failure is recorded separately for an operator to find.