Debugging ComfyUI: Why Your Index Variable Feels Ignored

Debugging custom nodes in ComfyUI can feel like trying to read the mind of an alien. You tweak an input, refresh your workflow, and expect the node to behave differently—but sometimes, it just… ignores you.

This post explores a specific debugging journey involving the `WAS_Load_Image_Batch` node. We’ll trace why changing the `index` variable feels like shouting into a void, uncovering hidden database states and API inconsistencies along the way.

The Symptom: The Ghost Index

It starts with a classic frustration: you set an input parameter—like `index`—and expect it to control exactly which image is loaded. However, when you switch modes or refresh your workflow, the node behaves as if that variable never existed.

The first step in solving this mystery is isolating where the data actually flows. By inspecting the code logic, we realize that the `index` input parameter is only actively utilized within the single_image mode. When you switch to incremental_image, the system completely bypasses that external variable.

This reveals a critical architectural disconnect. The node relies on an internal self.index for incremental loading, which is managed by a hidden SQLite database (was.db). These two indices—the one you see in the UI and the one stored internally—are completely separate entities that never communicate.

The API Confusion: insert vs. set

Naturally, trying to force these systems to talk to each other seems like the logical next step. You might look at the database wrapper class, WASDatabase, and assume it works exactly how you expect.

However, a closer inspection reveals that methods like insert() have been deprecated or renamed in recent versions of WAS Suite to set(). This is a common occurrence in software development: legacy code often lingers alongside updated APIs. Attempting to use the old method results in immediate errors, forcing you to realize that this isn’t just about your logic—it’s about the actual tools available.

The Final Realization

After piecing together these fragments, a clearer picture emerges. The node is designed with a strict separation of concerns: inputs are for selection, while state persistence is handled by hidden databases. Trying to force the UI input index to sync with the internal database would require breaking this architecture entirely.

The conclusion? It’s better to accept that `index` and `incremental_image` live in different worlds. By stopping here, you avoid a massive refactor of your workflow just to fix an architectural design choice made by the developers.