UI→API conversion assigns the wrong widget value when a node has a multi-type input

[morisms]

UI→API conversion assigns the wrong widget value when a node has a multi-type input

Environment

comfy-cli	1.18.0
ComfyUI	0.33.1 (Windows portable, python_embeded)
Python	3.10.11
OS / GPU	Windows, RTX 4090
Workflow	ComfyUI built-in template Text to Video (LTX-2.5)

Summary

When lowering a UI-format (canvas) workflow to API format, comfy-cli mis-assigns widgets_values for nodes whose schema contains a multi-type input (io.MultiType.Input, surfaced as a FLOAT,INT type). The multi-type input appears to be skipped when building the ordered list of widget-capable inputs, so every widget declared after it receives the value belonging to the previous one.

The result is a silently wrong graph that validates clean and then fails at runtime.

Concrete case

LTXVEmptyLatentAudio (comfy_extras/nodes_lt_audio.py) declares its inputs in this order:

frames_number : Int
frame_rate    : MultiType(Float, [Int])    <-- multi-type
batch_size    : Int
audio_vae     : Vae

The frontend stores "widgets_values": [97, 25, 1] (frames_number=97, frame_rate=25, batch_size=1).

In this workflow frames_number and frame_rate are both driven by links; only batch_size uses its widget value.

Expected — ComfyUI's own Workflow > Export (API):

"405:366": {
  "class_type": "LTXVEmptyLatentAudio",
  "inputs": {
    "frames_number": ["405:378", 1],
    "frame_rate":    ["405:359", 1],
    "batch_size":    1,
    "audio_vae":     ["405:386", 0]
  }
}

Actual — comfy --json run --workflow <canvas.json> --print-prompt:

"405:366": {
  "class_type": "LTXVEmptyLatentAudio",
  "inputs": {
    "batch_size":    25,
    "frames_number": ["405:378", 1],
    "frame_rate":    ["405:359", 1],
    "audio_vae":     ["405:386", 0]
  }
}

batch_size receives 25, which is frame_rate's widget value.

The sibling node EmptyLTXVLatentVideo in the same graph — width, height, length, batch_size, all plain Int, the first three linked — converts correctly ("batch_size": 1). The only structural difference between the two nodes is the multi-type input.

Consequence

The audio latent is built with batch size 25 while the video latent has batch size 1, and execution dies when the two are packed together:

node 405:344  SamplerCustomAdvanced
RuntimeError: Sizes of tensors must match except in dimension 2.
Expected size 1 but got size 25 for tensor number 1 in the list.
comfy/samplers.py:1282  in sample        -> pack_latents(latent_image.unbind())

comfy/utils.py:1381     in pack_latents  -> torch.cat(tensors, dim=-1)

Steps to reproduce

1. Open the built-in template Text to Video (LTX-2.5) in the ComfyUI frontend and save it (canvas format).
2. Run comfy --json run --workflow <saved.json> --print-prompt.
3. Inspect the LTXVEmptyLatentAudio node in the printed graph: batch_size is 25 instead of 1.
4. comfy run on the same file fails with the RuntimeError above. Pressing Run in the browser succeeds, and so does passing the frontend's Export (API) output to comfy run.

Possibly related

comfy workflow validate on the same graph reports, for the same field:

node 405:366, field frame_rate, code edge_type_mismatch
input 'frame_rate' expects FLOAT,INT but ComfyMathExpression[1] produces INT

INT is within the accepted set, so this warning is itself a false positive — which suggests multi-type inputs are not fully modelled in the type-checking layer either, not only in the widget-mapping path.

Workaround

Export the workflow with ComfyUI's Workflow > Export (API) and pass that file to comfy-cli instead of the canvas-format file.

[dosubot]

Hi @morisms! I'm Dosu and I'm helping the Comfy Org team.

Excellent bug report — I can confirm exactly where this breaks in the code.

The root cause is _is_widget_input() in comfy_cli/workflow_to_api.py. This function decides whether a schema input occupies a widgets_values slot. Its decision chain for string types is:

if input_type in {"INT", "FLOAT", "STRING", "BOOLEAN", "COMBO"}:
    return True, False
if input_type.startswith("COMFY_") and "COMBO" in input_type:
    return True, True
if not input_type.isupper():
    return True, False  # custom (lowercase) widget types
return False, False

A multi-type input like LTXVEmptyLatentAudio.frame_rate is reported by /object_info with a type string of "FLOAT,INT". This compound string:

• Is not in the {"INT", "FLOAT", ...} set
• Does not start with "COMFY_"
• Does pass "FLOAT,INT".isupper() (every alphabetic character is uppercase)

So it falls through to return False, False — classifying frame_rate as connection-only (no widget slot). The _schema_widget_pairs() walk then skips it entirely when consuming widgets_values, so frames_number takes slot 0 (97), and batch_size immediately takes slot 1 (25 — which was frame_rate's value), producing the wrong output you observed.

The fix would be to handle comma-separated type strings before the isupper() check — treating a type as widget-capable if any of its comma-separated alternatives is a known widget primitive:

if input_type in {"INT", "FLOAT", "STRING", "BOOLEAN", "COMBO"}:
    return True, False
# Multi-type (e.g. "FLOAT,INT") — widget if any alternative is a widget type
if "," in input_type:
    widget_primitives = {"INT", "FLOAT", "STRING", "BOOLEAN", "COMBO"}
    if any(t.strip() in widget_primitives for t in input_type.split(",")):
        return True, False
if input_type.startswith("COMFY_") and "COMBO" in input_type:
    return True, True
if not input_type.isupper():
    return True, False

Interestingly, the same file already handles comma-separated types correctly in _is_valid_connection() via split(",") for type-compatibility checks — the widget classification path just doesn't share that logic, which is likely also behind the false-positive edge_type_mismatch validation warning you noticed.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.