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

[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.