Skip to content

Normalize object-shaped manifest inputs in the workflow preflight check - #244

Open
OmarB97 wants to merge 1 commit into
lightningpixel:mainfrom
OmarB97:fix/normalize-object-shaped-manifest-inputs
Open

Normalize object-shaped manifest inputs in the workflow preflight check#244
OmarB97 wants to merge 1 commit into
lightningpixel:mainfrom
OmarB97:fix/normalize-object-shaped-manifest-inputs

Conversation

@OmarB97

@OmarB97 OmarB97 commented Jul 27, 2026

Copy link
Copy Markdown

Symptom

Workflow preflight rejects a run with "Image to Image needs an incoming text connection" on a node that only takes images and has a valid image edge connected. Reported in #241 (item 1).

Root cause

WorkflowExtension.inputs is documented as an array of plain type strings ('image' | 'text' | 'mesh' | 'audio'), and validateWorkflowPreflight matches declared input types against connected edges by strict equality (outputTypes.get(edge.source) === requiredType). Some extension manifests declare inputs as an array of objects instead (e.g. modly-Codex-image-extension's image-to-image node: { name, label, type, required } per slot). A string never equals such an object, so every declared input on that node is judged missing regardless of what's actually connected. formatType's fallback branch then renders the (object-typed) missing type as "text" unconditionally, which is what actually produces the misleading "needs an incoming text connection" message.

Fix

  • Normalize inputs once, in buildAllWorkflowExtensions (mockExtensions.ts) — the single place raw, untyped manifest JSON becomes a typed WorkflowExtension — mapping object entries to their .type field so everything downstream can trust the documented plain-string shape.
  • Make formatType (preflight.ts) fall back to String(type) instead of silently defaulting to "text", so a future malformed/unrecognized type fails loudly instead of mislabeling.

This addresses item 1 of #241 only. Items 2 (installer requirements build order) and 3 (Codex extension's own SDK bootstrap) in that report are separate, unrelated issues and are untouched here.

Verification

  • Added mockExtensions.test.mjs: reproduces the real image-to-image manifest shape (four named image slots as objects) and asserts buildAllWorkflowExtensions normalizes it to ['image','image','image','image']; also covers an already-plain-string inputs array (unchanged) and a node with no multi-input array (inputs stays undefined). Confirmed the first case fails against the pre-fix code and passes after.
  • Existing preflight.test.mjs: 6/6 still passing.
  • tsc --noEmit across the whole project: 0 errors.

WorkflowExtension.inputs is documented as an array of plain type
strings ('image' | 'text' | 'mesh' | 'audio'), and
validateWorkflowPreflight relies on that to match declared input types
against connected edges by strict equality. Some extension manifests
(e.g. modly-Codex-image-extension's image-to-image node) instead
declare inputs as an array of objects (name/label/type/required per
slot). A string never equals such an object, so every declared input
on that node is judged missing, and formatType's fallback branch
mislabels the (object-typed) missing type as "text" regardless of
what's actually missing — producing exactly the reported symptom:
'Image to Image needs an incoming text connection' on a node that
has a valid image connection.

Normalize inputs once, in buildAllWorkflowExtensions, at the manifest
boundary where raw untyped JSON becomes a typed WorkflowExtension —
mapping object entries to their .type field so everything downstream
can trust the documented shape. Also make formatType fall back to
String(type) instead of silently defaulting to 'text', so a future
malformed type fails loudly instead of mislabeling.

Addresses the first item in lightningpixel#241 (object-shaped inputs mislabeled as
text); the requirements-install-order and Codex-extension-SDK items
in that report are separate issues, untouched here.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant