ECS branch: rejected topology updates degrade silently at all three updateEndpoints call sites

[christian-byrne]

Found while writing the repros for #15577 and #15581 (PR #15592). Those two are instances of a class, and this is the third and worst instance. Branch feature/ecs-migration, head 9f6ab9adda.

The class

Every updateEndpoints call site on the branch swallows a rejected topology update into console.error and continues with degraded state. There are three, and each degrades differently:

Site	On rejection	Result
linkDeduplication.ts:158	logs, break	abandons the node's remaining moves (#15581)
LLink.ts:115	logs, falls through	caller proceeds as if the endpoint moved
node/slotLinks.ts:192	logs, return []	node keeps its old input layout; [] is indistinguishable from "nothing to replace"

None marks has_errors. None uses the repo's unified reportError. Raw console.error is auto-captured by Datadog RUM but untagged, so a load that silently re-wires a graph produces no searchable signal.

Why slotLinks.ts:192 is the worst of the three

const result = store.updateEndpoints(graphScopeOf(node.graph), updates, removals.map(...))
if (!result.ok) {
  console.error('Failed to replace node inputs', result.error)
  return []
}
node.inputs.splice(0, node.inputs.length, ...finalInputs)

The early return happens before the splice. So on a rejected batch the node keeps its previous input layout while the caller believes replaceNodeInputs ran, and the empty return value is the same value a successful no-op replacement produces. There is no way for a caller to tell the two apart.

Why this may already be a known break

replaceNodeInputs is the indexed-slot-replacement path. comfyui-promptchain (14,814 installs) does exactly node.inputs[i] = {...slot}, and it is the confirmed pack break on this branch. If promptchain's failure is a rejected replaceNodeInputs returning [], then the shim currently being scoped for it is being designed against a symptom rather than the cause.

Worth testing that before the shim is specified.

Asks

1. Decide what a rejected topology update should do. One decision for the class, not three patches.
2. At minimum, make replaceNodeInputs distinguishable: return a result type, or throw, rather than an empty array that means two different things.
3. Route these through reportError so they are searchable, and mark the node has_errors where a graph has actually been left mis-wired.

Related

• ECS branch: configure-time link dedup picks the wrong survivor and drops conflicting links silently #15577, ECS branch: one unmatched input name abandons a whole node's input-slot realignment on load #15581 — the other two instances, both with repros in test: reproduce #15577 and #15581 on the ECS branch #15592

[christian-byrne]

Tested. promptchain does not reach slotLinks.ts:192. The hypothesis in this issue's "Why this may already be a known break" section is false, and the shim being scoped for promptchain needs to change shape.

Test PR: #15595.

What promptchain actually does

Read from the pack, not the idiom as described. mobcat40/ComfyUI-PromptChain:

• js/lib/order-chain.js:123 updateInputLabels writes node.inputs[i] = { ...slot } for every input, called synchronously from the pack's onConnectionsChange (js/main.js:1315) and again in the following rAF (js/main.js:1322).
• js/main.js:507 trimEmptyAutogrowSlots then reads input.link != null to decide which trailing slots are empty, and removes the ones it thinks are empty with a raw inputs.splice.

link is a prototype accessor on NodeInputSlot, so the spread copy carries no link key at all. Second and later label passes therefore read every connected slot as disconnected.

The compound failure, measured on 9f6ab9adda with a 4-input node, 3 connected:

Arm	Slots removed by the pack's own trim
After the pack's label pass (ECS)	3 of 4, including all 3 connected
Live class slots, same fixture, same trim (control)	0

The node drops to 1 input. graph.serialize() still lists all three links targeting input slots the node no longer has.

The rejection path is not involved

Across every sequence tried — reentrant slot substitution from onConnectionsChange during removeInput, raw inputs.splice then removeInput, and reconnecting after both — updateEndpoints returned ok every time and console.error('Failed to replace node inputs') fired 0 times. The link store is keyed by node id and slot index, so replacing the slot object with a plain copy is invisible to it.

The :192 early return is still a real defect and still worth fixing. #15595 adds a forced-rejection arm that asserts it rather than reading it off the source: on a rejected batch the node keeps its old input layout and removeInput returns normally, so no caller can tell. Removing the return [] makes exactly that test fail.

What this means for the shim

The plan is "plain-object slots on push and indexed assignment". Indexed assignment is the right site. Intercepting the write is not enough, because promptchain never writes link; it reads it, and the copy has no link key to read.

The shim has to rehydrate the assigned plain object into a NodeInputSlot so the accessor comes back. Simulated that as a mutation: a set trap on node.inputs that does new NodeInputSlot(value, node) for a non-NodeInputSlot at a numeric index. Result across src/lib/litegraph/src/node/ + linkStore.test.ts + LLink.store.test.ts (130 tests): 124 passed, 0 regressions, and three it.fails markers flipped to passing, including the pre-existing disconnects through a plain-object input slot from #15578.

That is the whole delta. A pass-through shim that only routes mutations leaves promptchain broken.

cc @DrJKL