You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Can a flow-node producer create a node without a label? Enforce at the producer — the reader-side type cannot, because every node arrives through a cast #6331
Filed unassigned by the domain:ui @ objectui execution seat, PM session session_011SfZeFWrhGLHmfq61xbz4q (os-support-ai), as the accepted follow-up to #6287 (option C in that card's rebuttal). ⛔ Not claiming; recording so it is not carried in anyone's memory.
Where this came from
#6287's binding ruling had two items. Item 1 (drop description, a key FlowNodeSchema refuses) landed in PR #6330. Item 2 — "make label required on the inspector's node type" — was rebutted with a measurement and I accepted the rebuttal. This card is the part of item 2 that is a real question.
Making label required on the reader-side type produces tsc exit 0, ZERO errors. It catches nothing:
every node reaches this type through as FlowNodeLike[] casts out of Record<string, unknown>, and a cast bypasses a required member.
⚠️ And it is mildly harmful: node.label ?? '' and node.label || node.id are guards the optional type currently forces. A required label would let node.label.trim() compile against a value that genuinely is absent.
The repo has already adjudicated the identical question one layer over, in FlowDesignerNode's own doc comment:
a canvas holds nodes the user has dropped but not finished … typing it as the spec's would make the editor's own intermediate state unrepresentable
Why that is not the end of it
⭐ The measurement shows the reader-side type is the wrong enforcement point. It does not show the underlying question is answered. FlowNodeSchema requires label; the editor's intermediate state legitimately lacks it. Both can be true — but only if something guarantees a node acquires a label before it is saved.
The open question is about producers, not about the type:
Which code paths create a flow node? (canvas drop, paste, import, template instantiation, programmatic construction…)
Can any of them produce a node that reaches save without a label?
If no — what enforces it today, and is that enforcement visible, or is it an accident of every current producer happening to set one?
⛔ Do not answer this by changing the reader-side type — that is the move #6287 measured as a no-op. The enforcement point is wherever a node is constructed, where a cast cannot bypass it.
Suggested shape (⛔ not prescribing — this wants triage)
Census the producers first and report the count before building anything. If every producer already sets a label, the honest deliverable may be a pin at the producer boundary plus a comment recording why the reader type stays optional — which would also stop this question being re-opened a third time. If some producer can omit it, that is a live defect of the #6287 class and should be graded as such.
Filed unassigned by the
domain:ui@ objectui execution seat, PM sessionsession_011SfZeFWrhGLHmfq61xbz4q(os-support-ai), as the accepted follow-up to #6287 (option C in that card's rebuttal). ⛔ Not claiming; recording so it is not carried in anyone's memory.Where this came from
#6287's binding ruling had two items. Item 1 (drop
description, a keyFlowNodeSchemarefuses) landed in PR #6330. Item 2 — "makelabelrequired on the inspector's node type" — was rebutted with a measurement and I accepted the rebuttal. This card is the part of item 2 that is a real question.What was measured (in #6287, on
origin/main)Making
labelrequired on the reader-side type producestscexit 0, ZERO errors. It catches nothing:node.label ?? ''andnode.label || node.idare guards the optional type currently forces. A requiredlabelwould letnode.label.trim()compile against a value that genuinely is absent.The repo has already adjudicated the identical question one layer over, in
FlowDesignerNode's own doc comment:Why that is not the end of it
⭐ The measurement shows the reader-side type is the wrong enforcement point. It does not show the underlying question is answered.
FlowNodeSchemarequireslabel; the editor's intermediate state legitimately lacks it. Both can be true — but only if something guarantees a node acquires a label before it is saved.The open question is about producers, not about the type:
label?FlowNodeSchemarequireslabel, so the likely answer is the same class FlowNodeInspector's local FlowNode admits adescriptionkey the spec's strict FlowNodeSchema rejects — and its FlowEdge twin already disagrees with FlowEdgeInspector's #6287 just fixed fordescription: a refusal at save time, discovered by the author rather than by a gate.⛔ Do not answer this by changing the reader-side type — that is the move #6287 measured as a no-op. The enforcement point is wherever a node is constructed, where a cast cannot bypass it.
Suggested shape (⛔ not prescribing — this wants triage)
Census the producers first and report the count before building anything. If every producer already sets a label, the honest deliverable may be a pin at the producer boundary plus a comment recording why the reader type stays optional — which would also stop this question being re-opened a third time. If some producer can omit it, that is a live defect of the #6287 class and should be graded as such.
Related
descriptionkey the spec's strict FlowNodeSchema rejects — and its FlowEdge twin already disagrees with FlowEdgeInspector's #6287 / PR fix(app-shell): stop the flow node inspector writing a spec-refuseddescription, and converge the duplicated node/edge shapes #6330 — where this was measured and split off (the accepted rebuttal is in the ACCEPT comment there)FlowDesignerNode's doc comment — the prior adjudication of the same layer questionActionParamis declared twice in app-shell and the two copies disagree on five members —ActionDefaultInspector.tsx:266vsActionPreview.tsx:47#6329 — a separate duplicate-shape finding from the same run