Smelting 400 Errors Root Cause Found

Two separate causes were behind the failures. The first was a Python boolean bug built around or None. In practice, False or None becomes None, which meant the IPAdapter override path was being ignored and the system kept defaulting to True even when the custom node was missing.

The second issue was with ComfyUI image loading. The pipeline was trying to pass arbitrary OS file paths into a node that does not read them that way. The correct flow is to upload the reference image through /upload/image first, then let ComfyUI work from that uploaded reference.

Both root causes were fixed, but the session also included a frontend correction. The Smelting UI now has a visible error state so failures don’t silently dump the user back into a reset state with no explanation. That part matters because a hidden failure is harder to debug than a failed request.

Why This Bug Was Costly

This one was expensive because it looked like instability instead of two concrete bugs. One issue lived in Python state handling and the other lived in the ComfyUI handoff, so the failure presented like a vague pipeline problem when it was really a backend logic bug plus an invalid input contract.

The UI piece made it worse. If the request fails and the screen gives no clear failure state, the user is left reading the system as flaky. Adding a real error surface was important because the debugging problem was not only getting the request to succeed, it was making failure readable when it did not.

Diff Log: Smelting 400 Root Cause

The core bug was treating a boolean override and a file path flow as if they were both valid when they were not. The fix was to stop collapsing False into None and to upload images before handing them to ComfyUI.

Bug / Fix

- ipadapter_override = userValue or None
+ ipadapter_override = userValue if userValue is not None else defaultValue

- LoadImage reads arbitrary OS path directly
+ POST reference to /upload/image first, then load uploaded image in ComfyUI