Skip to content

Workflow preflight rejects nodes with object-shaped manifest inputs (mislabels missing type as "text") #241

Description

@OmarB97

Modly bug report — round 2 (Linux, RTX 5090 / Blackwell sm_120, v0.4.1)

Follow-up to modly#236–239. All items reproduced on the same box.

1. Workflow preflight rejects any node whose manifest declares object-shaped inputs

validateWorkflowPreflight computes:

const requiredTypes = [...new Set(ext.inputs ?? [ext.input])]
const hasMatchingInput = incomingEdges.some((edge) => outputTypes.get(edge.source) === requiredType)

outputTypes holds type strings ("image", "mesh", …), but a manifest may declare inputs as objects — e.g. modly-Codex-image-extension's image-to-image node:

"input": "image",
"inputs": [
  {"name": "front", "label": "Primary image", "type": "image", "required": true},
  {"name": "left",  "label": "Image 2", "type": "image", "required": false}
]

Because a string never equals an object, every connection is judged missing, the workflow can't run, and formatType(<object>) renders the missing type as "text" — so the user sees "Image to Image needs an incoming text connection" on a node that takes images and has a valid image edge. Extremely hard to diagnose from the UI.

Suggested fix: normalize in the manifest parser — inputs: (n.inputs ?? []).map(i => typeof i === 'string' ? i : i.type) — and keep the object form for labels/required-ness in a separate field (inputLabels already exists). Also make formatType fall back to String(t) rather than defaulting to "text".

Workaround: delete the inputs array from the extension manifest, leaving input: "image".

2. Extension installer builds requirements in the wrong order (flash-attn before torch)

Installing UniRig-workspace_extension_modly and MOSS-SoundEffect-modly-extension fails during setup with:

ModuleNotFoundError: No module named 'torch'
ERROR: Failed to build 'flash_attn' when getting requirements to build wheel

flash-attn's setup.py imports torch at build time, so it must be installed after torch, with --no-build-isolation. The installer appears to install the whole requirements file in one pass with build isolation on.

Suggested fix: install torch/torchvision first from the requirements set, then the rest with --no-build-isolation; or document a build_order manifest key.

3. modly-Codex-image-extension doesn't bootstrap its own SDK on install

The extension fails at first run with codex_app_server is not importable. Its README documents the pinned source (git+https://github.com/openai/codex.git@…#subdirectory=sdk/python) and says setup installs it, but a fresh GitHub install did not — the extension venv lacked the package until installed manually.

Environment note (not a bug, may help other users)

The official trellis-2 extension produces degenerate output on any torch-2.7-era stack; rebuilding per microsoft/TRELLIS.2#143 (torch nightly + source-built flash-attn/flex_gemm/cumesh/o-voxel, SPARSE_CONV_BACKEND=flex_gemm) fixes it. Details in lightningpixel/modly-trellis2-extension#3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions