null entries in a subgraph host's widgets_values load as undefined on >=1.47, silently breaking pre-refactor workflows

[AI4VFX]

What happened?

On frontend 1.46.x, a null entry in a subgraph host node's widgets_values meant "no host override — fall through to the interior widget's value". That fallthrough is gone on ≥1.47.9: host widgets_values is now the authoritative value (it seeds the display and compiles into the prompt), and a null entry loads as undefined rather than deferring to the interior node.

The result is that any workflow saved before the ADR-0009 / widget-store refactor, whose host widgets_values contains nulls, now opens with dead promoted widgets — no error, no warning, no migration.

This is not hypothetical: nulling those entries was the documented recovery workaround for #13601, so the workflows most likely to hit this are the ones whose owners followed the advice in that thread.

Evidence

A workflow saved under 1.46.x, subgraph host node with:

"widgets_values": [null, null, null, null, null, null, null, 3358]

loaded on frontend 1.47.11 / core v0.29.2 — 5 of the 8 promoted widgets come back with value: undefined:

value        (customtext) -> ""          ok
value_1      (number)     -> undefined   BROKEN
value_2      (number)     -> undefined   BROKEN
value_3      (number)     -> undefined   BROKEN
start_index  (number)     -> undefined   BROKEN
value_4      (number)     -> undefined   BROKEN
                            (the one non-null entry, 3358, loads fine)

The interior nodes still hold their real values — only the host-level view is broken — so the information needed to migrate is present in the file.

Steps to Reproduce

1. On a build ≤1.46.15, create a subgraph and promote a few numeric widgets to the host node.
2. Set every entry of the host node's widgets_values to null (the Editing a promoted widget in the properties side panel permanently freezes that widget on the subgraph node (stale host widgets_values shadow) #13601 workaround), or otherwise obtain a workflow saved with nulls there.
3. Open that workflow on ≥1.47.9.
4. Inspect the host node's promoted widgets: the numeric ones have value === undefined and render blank/NaN instead of picking up the interior values.

How is this affecting you?

Workflows that opened fine before a routine frontend update now open with unusable promoted controls, and the failure is silent — nothing in the console indicates a migration happened or failed. Recovery means hand-editing JSON to write concrete values into widgets_values, which requires knowing the slot ordering.

Because the null-out was the recommended fix in #13601, this preferentially breaks workflows belonging to users who reported or worked around that bug.

Suggested fix

A load-time migration: when a host widgets_values entry is null/absent, resolve the value from the linked interior widget (the pre-1.47 semantics) instead of leaving it undefined. That keeps the new authoritative-host-value model while letting legacy files self-heal on open.

ComfyUI Frontend Version

1.47.11 (core v0.29.2). The behaviour change was already present at 1.47.9; not tested on 1.49.x, which landed #10392 (widgets_values_named) in this same serialization area.

Browser

Chrome — the broken state is in the loaded graph model, so it is not browser-specific.

Additional Context

Follow-up to #13601 (the original freeze, which I can confirm is fixed on 1.47.11 — see my comment there). This issue is the inverse failure introduced by the same refactor.

[coderabbitai]

🔗 Related PRs

#14251 - fix: keep missing node packs across runs [open]
#14460 - fix: numeric combo widgets are falsely marked invalid [open]
#14461 - fix: preserve subgraph node size when editing or promoting widgets (FE-853) [open]

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[dosubot]

This is a valid regression. Looking at the current _applyPromotedWidgetValues() implementation, the root cause is clear [1]:

const value =
  quarantineValuesByInputName.get(input.name) ??
  widgetValues?.[valueIndex]
if (value !== undefined) {
  useWidgetValueStore().setValue(input.widgetId, value)
}

The null !== undefined check means null entries are passed through to setValue(), which stores null as the widget's value. This is the post-refactor semantic from PR #13322 where null became an explicit stored value rather than a fallthrough marker [2]. Pre-1.47, null in host widgets_values meant "no override — use the interior widget's value"; post-refactor it means "the value is literally null", which surfaces as undefined / blank in the UI.

The suggested fix — resolving null entries against the linked interior widget value at load time — seems like the right approach. In _applyPromotedWidgetValues(), a null entry could be treated the same as undefined (i.e., skipped), which would let the interior widget's already-registered store value serve as the default. This preserves the new authoritative-host model for any non-null entry while allowing legacy workflows to self-heal.

No existing migration logic covers this case — the quarantine path only handles specific promotion error recovery, not general null entries [3].

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[AI4VFX]

That analysis matches the observed behaviour — thanks. I checked _applyPromotedWidgetValues() at e1718dac and the value !== undefined guard is indeed what lets a null through to setValue().

One addition, because it answers the "does it still happen on latest?" question without needing a repro run on 1.49.x. Four lines above, in configure():

super.configure(info)
if (!info.widgets_values_named || !LiteGraph.namedValuesRestore)
  this._applyPromotedWidgetValues(info.widgets_values)

The widgets_values_named restore path from #10392 (shipped in 1.49.2) bypasses _applyPromotedWidgetValues() entirely — but only for workflows that have a widgets_values_named key. Legacy workflows by definition do not, so they still take the positional path and still hit the null → stored-null behaviour. The named-values work doesn't cover the affected files.

That also means the fix stays worthwhile after #10392: the positional branch remains the load path for every pre-1.49 workflow, indefinitely.

On the suggested one-line change (treating null as skip, so the interior widget's registered store value stands) — one thing worth deciding explicitly is whether null should ever be a legitimate stored value for a promoted widget. If it can be, a version-gated migration would be safer than changing the guard unconditionally. If it cannot, skipping is clean and self-healing for legacy files with no flag-day needed.

Happy to test a fix against my affected workflow if a PR appears — I have a reproducing file and a scripted check that reports which promoted widgets come back undefined.

[christian-byrne]

RCA of record for this bug family (#14495, #14488, #13601, #11297): promoted subgraph widget ownership — full dossier.

Your read is right and it generalises. All four are the same root cause: the promoted widget's value lives in widgetValueStore keyed to the host (graphId:nodeId:name), ADR 0009 makes the host authoritative and the interior widget a schema/default provider only — but the host-owned value has no durable home. input-disconnected deletes the store entry and _setWidget re-registers it seeded from interiorWidget.value (src/lib/litegraph/src/subgraph/SubgraphNode.ts). Your null case is the load-time face of it; #14495 is the runtime face.

Fix in flight: #14955, which implements exactly the load-time migration you suggested — null is treated as "no host override" in _applyPromotedWidgetValues and in the promoted widget's value/callback bridge, so the interior value stands. Unreviewed as of now.