jaeone94 74147d7ee2 feat: lift boundary-exposed validation errors to the subgraph host (#13542)
## Summary

Backend validation errors (`node_errors`) are reported against the
**flattened** prompt, so an error whose real fix lives on a subgraph
host node gets attached to an interior node the user may never open —
and, after ADR 0009, often *cannot* meaningfully fix there. This PR
re-surfaces a validation error onto the subgraph host node **when — and
only when — the error's subject (the specific input/widget named by
`extra_info.input_name`) is exposed through the subgraph boundary**.

## Why this is needed

Two concrete situations motivated this, both observed in real workflows:

1. **Broken link at the host.** Root node A should feed subgraph host B,
whose boundary input is linked to interior node C. If the A→B link is
missing, the backend flattens the prompt, sees C with no resolved input,
and raises `required_input_missing` **on C** (`"B:C"`). The actual fix —
connect B's input — is one level up, on a node the error never points
at.
2. **Host-owned widget values.** Per ADR 0009 (subgraph promoted widgets
use linked inputs), a promoted widget's value is owned by the host
`SubgraphNode`; the interior widget only supplies schema/defaults. When
the backend raises `value_not_in_list` (or min/max violations) for that
value, attributing it to the interior node is factually wrong — the
value that failed validation *is the host's value*.

This continues the direction of #13059, which moved **missing-model**
detection identity to `{hostExecutionId, hostWidgetName}` with the
interior path kept as diagnostics. That was possible in the FE pre-scan;
this PR applies the same ownership principle to **backend-received**
errors via a receive-side mapping, since the backend cannot know about
subgraph boundaries in a flattened prompt.

## The rule (design)

> Lift an error from interior node N to host H **iff** N's input slot
named by the error is linked to the containing subgraph's boundary
(`SubgraphInput`). Apply the same test again at H (boundary-by-boundary,
matching ADR 0009's chaining principle) and stop at the first level
where the subject is no longer boundary-linked — that node is where the
user can actually fix it.

The predicate is **structural (boundary exposure), not data-flow**.

### In scope — examples

- `required_input_missing` on interior `"12:5"` whose input is fed by
the boundary → surfaces on host `12`'s input slot (red slot ring on the
host, errors-tab card titled/located at the host, message names the
host's `SubgraphInput.name`).
- `value_not_in_list` / `value_smaller_than_min` /
`value_bigger_than_max` on a promoted interior widget → surfaces on the
host's promoted widget. Nested hosts chain: `"1:2:3"` lifts to `"1:2"`,
and further to `"1"` only if `1:2`'s own slot is boundary-linked too.
- Clearing follows the surface: connecting the highlighted host input or
fixing the host widget clears the underlying interior (raw) error —
range-guarded per target, so a still-out-of-range host value does
**not** clear.

### Out of scope — examples

- **No value-flow ancestry.** All in the root graph: A's widget links to
B, B's to C, and C rejects the value that originated at A → the error
**stays on C**. Following same-graph links to a "root cause" node is
explicitly not this feature.
- Errors without an `input_name` subject, node-level types
(`exception_during_validation`, `dependency_cycle`, image-not-loaded),
and unknown validation types — never lifted. Unknown types stay
node-scoped to match how the error catalog renders them (the shared
`isNodeLevelValidationError` in `executionErrorUtil` encodes this, and
the catalog derives its node-level rules from the same set).
- Runtime execution errors (exceptions during a run) — validation
responses only.
- Interior errors whose input is fed by another interior node — fixable
in place, stay in place.
- Fan-out display dedupe: when one boundary input feeds multiple
interior nodes and the host slot is unconnected, each interior error
lifts to the same host slot as a separate panel line. A single fix
(connecting the host input) clears all of them — the clearing
translation already fans out — so the duplication is cosmetic.
Display-level dedupe is a follow-up; deduping inside the lift would
break the one-source-per-error clearing contract.
- Reactive re-lifting on graph topology edits while errors are displayed
(invariant documented on the computed; follow-up), and deriving the
error catalog's full validation rule table from the shared
classification (follow-up; the node-level type set and the
image-not-loaded predicate are already single-sourced in
`executionErrorUtil` and consumed by both the lift and the catalog).

## Changes

- **What**: New pure module
`core/graph/subgraph/liftNodeErrorsToBoundary.ts` — per-error, fail-open
record transform (unresolvable ids/slots/links leave the error where the
backend put it; raw payload is never mutated). `executionErrorStore`
derives `surfacedNodeErrors` from it and display consumers switch over
(errors tab grouping, canvas node/slot flags, Vue node badges,
app-mode/linear hints); raw `lastNodeErrors` remains the source of truth
for mutation. Host-side clearing translates through the lift's
diagnostics fields (`source_execution_id` / `source_input_name`) with a
per-target range guard.
- **Breaking**: None. No persistence/serialization changes; interior
identity survives as diagnostics metadata only (ADR 0009 language).

## Review Focus

- The lift predicate lives entirely on link topology
(`LLink.originIsIoNode` → `SubgraphInput`) — no
`proxyWidgets`/promotion-store style source authority is reintroduced.
- `clearSlotErrorsWithRangeCheck` now resolves clear targets first and
range-checks each target's raw errors; the lifted-path twin of the
existing range-retention test pins this.
- `useProcessedWidgets` deliberately stays on the raw record: host
promoted widgets already map to interior errors via
`widget.sourceExecutionId`, so an interior widget keeps its local red
hint when the user opens the subgraph (hint layer vs surface layer).
- Unit coverage is carried by the pure module (real litegraph subgraph
fixtures, incl. nested recursion, promoted widgets via
`promoteValueWidgetViaSubgraphInput`, ordering, fail-open/no-mutation);
one e2e pins the user-visible contract (host ring + host slot dot +
interior clean).

## Screenshots

### Before 


https://github.com/user-attachments/assets/81e5c4db-515d-4f1f-8f8a-e07ac490510f

### After



https://github.com/user-attachments/assets/2949da06-a049-41c1-a480-98ee28333bf2
2026-07-14 14:39:20 +00:00
2026-06-26 22:54:04 +00:00
2024-06-12 20:22:24 -04:00
2026-07-11 03:49:03 +00:00
2026-01-27 17:59:19 -08:00

ComfyUI_frontend

Official front-end implementation of ComfyUI.

Website Discord Matrix

Release Schedule

The project follows a structured release process for each minor version, consisting of three distinct phases:

  1. Development Phase - 2 weeks

    • Active development of new features
    • Code changes merged to the development branch
  2. Feature Freeze - 2 weeks

    • No new features accepted
    • Only bug fixes are cherry-picked to the release branch
    • Testing and stabilization of the codebase
  3. Publication

    • Release is published at the end of the freeze period
    • Version is finalized and made available to all users

Nightly Releases

Nightly releases are published daily at https://github.com/Comfy-Org/ComfyUI_frontend/releases.

To use the latest nightly release, add the following command line argument to your ComfyUI launch script:

--front-end-version Comfy-Org/ComfyUI_frontend@latest

Overlapping Release Cycles

The development of successive minor versions overlaps. For example, while version 1.1 is in feature freeze, development for version 1.2 begins simultaneously. Each feature has approximately 4 weeks from merge to ComfyUI stable release (2 weeks on main, 2 weeks frozen on RC).

Example Release Cycle

Week Date Range Version 1.1 Version 1.2 Version 1.3 Patch Releases
1-2 Mar 1-14 Development - - -
3-4 Mar 15-28 Feature Freeze Development - 1.1.0 through 1.1.13 (daily)
5-6 Mar 29-Apr 11 Released Feature Freeze Development 1.1.14+ (daily)
1.2.0 through 1.2.13 (daily)
7-8 Apr 12-25 - Released Feature Freeze 1.2.14+ (daily)
1.3.0 through 1.3.13 (daily)

Release Summary

Major features

v1.5: Native translation (i18n)

ComfyUI now includes built-in translation support, replacing the need for third-party translation extensions. Select your language in Comfy > Locale > Language to translate the interface into English, Chinese (Simplified), Russian, Japanese, Korean, or Arabic. This native implementation offers better performance, reliability, and maintainability compared to previous solutions.

More details available here: https://blog.comfy.org/p/native-localization-support-i18n

v1.4: New mask editor

https://github.com/Comfy-Org/ComfyUI_frontend/pull/1284 implements a new mask editor.

image

v1.3.22: Integrated server terminal

Press Ctrl + ` to toggle integrated terminal.

https://github.com/user-attachments/assets/eddedc6a-07a3-4a83-9475-63b3977f6d94

v1.3.7: Keybinding customization

Basic UI

image

Reset button

image

Edit Keybinding

image image

rec.webm

v1.2.4: Node library sidebar tab

Drag & Drop

https://github.com/user-attachments/assets/853e20b7-bc0e-49c9-bbce-a2ba7566f92f

Filter

https://github.com/user-attachments/assets/4bbca3ee-318f-4cf0-be32-a5a5541066cf

v1.2.0: Queue/History sidebar tab

https://github.com/user-attachments/assets/86e264fe-4d26-4f07-aa9a-83bdd2d02b8f

QoL changes

v1.3.32: **Litegraph** Nested group

https://github.com/user-attachments/assets/f51adeb1-028e-40af-81e4-0ac13075198a

v1.3.24: **Litegraph** Group selection

https://github.com/user-attachments/assets/e6230a94-411e-4fba-90cb-6c694200adaa

v1.3.4: **Litegraph** Auto widget to input conversion

Dropping a link of correct type on node widget will automatically convert the widget to input.

rec.webm

v1.3.4: **Litegraph** Canvas pan mode

The canvas becomes readonly in pan mode. Pan mode is activated by clicking the pan mode button on the canvas menu or by holding the space key.

rec.webm

v1.2.62: **Litegraph** Show optional input slots as donuts

GYEIRidb0AYGO-v

v1.2.44: **Litegraph** Double click group title to edit

https://github.com/user-attachments/assets/5bf0e2b6-8b3a-40a7-b44f-f0879e9ad26f

v1.2.39: **Litegraph** Group selected nodes with Ctrl + G

https://github.com/user-attachments/assets/7805dc54-0854-4a28-8bcd-4b007fa01151

v1.2.38: **Litegraph** Double click node title to edit

https://github.com/user-attachments/assets/d61d5d0e-f200-4153-b293-3e3f6a212b30

v1.1.8: **Litegraph** hides text overflow on widget value

https://github.com/user-attachments/assets/5696a89d-4a47-4fcc-9e8c-71e1264943f2

Developer APIs

v1.6.13: prompt/confirm/alert replacements for ComfyUI desktop

Several browser-only APIs are not available in ComfyUI desktop's electron environment.

  • window.prompt
  • window.confirm
  • window.alert

Please use the following APIs as replacements.

// window.prompt
window['app'].extensionManager.dialog
  .prompt({
    title: 'Test Prompt',
    message: 'Test Prompt Message'
  })
  .then((value: string) => {
    // Do something with the value user entered
  })

image

// window.confirm
window['app'].extensionManager.dialog
  .confirm({
    title: 'Test Confirm',
    message: 'Test Confirm Message'
  })
  .then((value: boolean) => {
    // Do something with the value user entered
  })

image

// window.alert
window['app'].extensionManager.toast.addAlert('Test Alert')

image

v1.3.34: Register about panel badges
app.registerExtension({
  name: 'TestExtension1',
  aboutPageBadges: [
    {
      label: 'Test Badge',
      url: 'https://example.com',
      icon: 'pi pi-box'
    }
  ]
})

image

v1.3.22: Register bottom panel tabs
app.registerExtension({
  name: 'TestExtension',
  bottomPanelTabs: [
    {
      id: 'TestTab',
      title: 'Test Tab',
      type: 'custom',
      render: (el) => {
        el.innerHTML = '<div>Custom tab</div>'
      }
    }
  ]
})

image

v1.3.22: New settings API

Legacy settings API.

// Register a new setting
app.ui.settings.addSetting({
  id: 'TestSetting',
  name: 'Test Setting',
  type: 'text',
  defaultValue: 'Hello, world!'
})

// Get the value of a setting
const value = app.ui.settings.getSettingValue('TestSetting')

// Set the value of a setting
app.ui.settings.setSettingValue('TestSetting', 'Hello, universe!')

New settings API.

// Register a new setting
app.registerExtension({
  name: 'TestExtension1',
  settings: [
    {
      id: 'TestSetting',
      name: 'Test Setting',
      type: 'text',
      defaultValue: 'Hello, world!'
    }
  ]
})

// Get the value of a setting
const value = app.extensionManager.setting.get('TestSetting')

// Set the value of a setting
app.extensionManager.setting.set('TestSetting', 'Hello, universe!')
v1.3.7: Register commands and keybindings

Extensions can call the following API to register commands and keybindings. Do note that keybindings defined in core cannot be overwritten, and some keybindings are reserved by the browser.

app.registerExtension({
  name: 'TestExtension1',
  commands: [
    {
      id: 'TestCommand',
      function: () => {
        alert('TestCommand')
      }
    }
  ],
  keybindings: [
    {
      combo: { key: 'k' },
      commandId: 'TestCommand'
    }
  ]
})
v1.3.1: Extension API to register custom topbar menu items

Extensions can call the following API to register custom topbar menu items.

app.registerExtension({
  name: 'TestExtension1',
  commands: [
    {
      id: 'foo-id',
      label: 'foo',
      function: () => {
        alert(1)
      }
    }
  ],
  menuCommands: [
    {
      path: ['ext', 'ext2'],
      commands: ['foo-id']
    }
  ]
})

image

v1.2.27: Extension API to add toast messagei

Extensions can call the following API to add toast messages.

app.extensionManager.toast.add({
  severity: 'info',
  summary: 'Loaded!',
  detail: 'Extension loaded!',
  life: 3000
})

Documentation of all supported options can be found here: https://primevue.org/toast/#api.toast.interfaces.ToastMessageOptions

image

v1.2.4: Extension API to register custom sidebar tab

Extensions now can call the following API to register a sidebar tab.

app.extensionManager.registerSidebarTab({
  id: 'search',
  icon: 'pi pi-search',
  title: 'search',
  tooltip: 'search',
  type: 'custom',
  render: (el) => {
    el.innerHTML = '<div>Custom search tab</div>'
  }
})

The list of supported icons can be found here: https://primevue.org/icons/#list

We will support custom icons later.

image

v1.10.9: Selection Toolbox API

Extensions can register commands that appear in the selection toolbox when specific items are selected on the canvas.

app.registerExtension({
  name: 'TestExtension1',
  commands: [
    {
      id: 'test.selection.command',
      label: 'Test Command',
      icon: 'pi pi-star',
      function: () => {
        // Command logic here
      }
    }
  ],
  // Return an array of command IDs to show in the selection toolbox
  // when an item is selected
  getSelectionToolboxCommands: (selectedItem) => ['test.selection.command']
})

The selection toolbox will display the command button when items are selected: Image

Contributing

We welcome contributions to ComfyUI Frontend! Please see our Contributing Guide for:

  • Ways to contribute (code, documentation, testing, community support)
  • Development setup and workflow
  • Code style guidelines
  • Testing requirements
  • How to submit pull requests
  • Backporting fixes to release branches

Development

For detailed development setup, testing procedures, and technical information, please refer to CONTRIBUTING.md.

i18n

See locales/README.md for details.

Storybook

See .storybook/README.md for component development and visual testing documentation.

Troubleshooting

For comprehensive troubleshooting and technical support, please refer to our official documentation:

Description
Official front-end implementation of ComfyUI
Readme GPL-3.0 1.1 GiB
Languages
TypeScript 83%
Vue 15.2%
Astro 0.4%
CSS 0.4%
MDX 0.4%
Other 0.6%