AnyBus Node Labels Reset to 1-5 on Refresh

[plenopticon]

Whenever the workflow refreshes, the first 5 labels in the AnyBus Node reset to 01-05. This happens regardless of the node type connected. The connections still work, but i have to reconnect the initial input to get the labels back, which treats it as a new connection and disconnects all downstream connections to that channel's output.

The simple solution is reserving 1-5 for temporary use and use 6+ for persistent connections, but curious if im missing anything.

Has anyone else experienced this or found a fix?

Thanks in advance!

[franksushiboycom]

Has anyone else experienced this or found a fix?

Same here.

[Codrus0]

TLDR: It's tied to localized names on the default inputs and outputs.

Let me start with a caveat that I've only really started digging into the underlying JS/Python code for ComfyUI this week (outside of a little poking into node evaluation code), so almost all of this is new to me. However, I've debugged AnyBus today far enough to know what's happening, and I'll start poking around towards a solution to propose. Someone familiar with ComfyUI coding ought to be able to propose a real solution very quickly with what I have. (I've also run out of time to spend more time on this today, so I'll share what I know.)

The names of the inputs are set properly in the code when you connect an input to another node, but all inputs and outputs on an AnyBus node when it is first created also have a localized_name property, with the same values as the default empty names: "* 01", "*02", and so on. So it doesn't matter what the code sets because ComfyUI overrides them with the localized names. I hacked the connectInput routine to look for and remove a localized name on an input when it sets a connection and everything works! That's obviously not the right solution, but it was enough to confirm my suspicions.

It's also tied to the default number of inputs configured in the MaraScottAnyBusNodeWidget structure in AnyBus_v2.js. When you add new inputs, the new ones don't get localized names. That's why it's the first five inputs.

If I change the default number of inputs, that changes which inputs have localization_name properties assigned to them. Similarly, if I use the node as is and reduce the number of inputs from 5 to 3 and then increase it back to 5, #4 and #5 start working properly.

I know that the localized names aren't being set directly in AnyBus, so my best guess is that it happens somewhere in the ComfyUI front end code when it first initializes a node. I just figured out the localization part a few minutes ago, and haven't looked into how ComfyUI performs that initialization at all. Maybe there's a flag to tell it not to generate a localized name because an input is dynamic?

In any case, I'm fairly confident the solution is to make sure the initial inputs and outputs do not get localized at creation time.

[Codrus0]

Based on what I'm seeing, the relevant code is in ComfyUI in litegraphservice.ts. It receives a list of all of the inputs and tries to translate each one.

this.addInput(inputName, inputType, {
...shapeOptions,
localized_name: st(nameKey, inputName)
})

It calls this function in 818n.ts:

export function st(key: string, fallbackMessage: string) {
return te(key) ? t(key) : fallbackMessage
}

So the ComfyUI library code fallback is to set up the localized name to the same as the name.

My initial thought s that this looks like a ComfyUI bug, not a bug in AnyBus. The underlying litegraph library ALREADY falls back to the name property when the localized_name property isn't there, so ComfyUI's behavior isn't needed.

Alternatively, I suppose there's a way to force AnyBus to create those inputs later, since dynamically adding them later doesn't go through the translation path, but that might be fragile.

[Codrus0]

Created an issue for the Comfy Front End team to look at.

Comfy-Org/ComfyUI_frontend#2998

It contains a link to this issue.

Tomorrow, I'll experiment with a patch to fix this in AnyBus. My proposed idea is to check to see whether there's a localized_name, and if so update it if it's different from the new name. Something along the lines of this (completely untested!) code:

if (node.inputs[slot].localized_name && node.inputs[slot].localized_name != newName ) {
node.inputs[slot].localized_name = newName
}

Basically, make this sort of change everywhere the code updates an input or output name. If they later remove the localized names, it won't add them.

[Codrus0]

Also created a new issue on AnyBus raised by this investigation.

"AnyBus does not respect localized names."
#196

The code I suggested above isn't the right code as it doesn't respect localization names either, but I think synchronizing localized names consistently will solve both issues. Will try to code up a fix but not tonight.

[Codrus0]

In the patch I've been working on, I've updated the JS code to always update name and localized_name together..

The remaining problem: When you switch languages or load from a saved workflow, that same set of five inputs gets overwritten with the default names. There's an easy workaround which is for a user to recreate the node; that causes all the inputs to be connected to the new node, and setting up connections properly updates the inputs.

Still, while an improvement, forcing someone to recreate nodes is not great. Here's why those entries are still getting clobbered:

1. The ComfyUI front end creates new nodes by starting with a data structure that includes info provided by the node's Python definition. This info includes everything related to inputs and outputs specified in the Python code. Comfy passes it over to the node's JS code to configure it further.

AnyBus provides a static list of parameters -- the bus input, and a fixed list of 24 inputs. The configuration code later trims the inputs list to the number of inputs specified in the "Nb inputs" widget. This disconnect is also why the preview for a new AnyBus node shows 24 inputs, but after you create it you see the default (5). (The fact that it's statically configured for 24 inputs while the JS code has a maximum of 25 is causing issue 195.)

In any case, because all the input parameters are created from the static python definition, Comfy uses those names to set the name and localized_name entries for all of those inputs.

2. When you load a workflow from a JSON file (and I'm fairly sure the localization code serializes a workflow to change languages), the code to load that workflow goes through a few steps, the first of which is to create a new node for each node in the workflow, as described above. For each node, it merges the newly created node with the serialized JSON data for that node. If you want to follow along, this is in the configure(data: any) function in litegraphService.ts in the comfy front end.

The process of merging the new node with the archived data deliberately overrides some of the archived data with data from the new node:

      for (const key of ['name', 'type', 'shape', 'localized_name']) {
        if (current[key] !== undefined) {
          result[key] = current[key]
        }
      }

So even though my code change is properly saving localized names and regular names, that all gets blown away and replaced with the python names for those parameters. And that's the bug. And because the input list is already trimmed to the default before the merge, only the first 5 parameters get clobbered, similar to the original behavior.

I see a couple of possible solutions:

1. Hook into a later step in the loading process and sync all the inputs on an AnyBus node after it loads. This feels like a brute force solution, but it's in the same spirit of the code in the Comfy Front End, which is to preferentially use the input and output names defined in a node's code over whatever is stored inside the serialized data. If someone changed an output name on a custom node hooked into AnyBus, AnyBus would pick up the change. A sync is also likely a requirement to properly change to a different localization.

2. A more significant change in the code would be to not create a static parameter list in the Python code. That list is what's causing some of these behaviors right now. For the localization reason given above, I don't think that removing all the static inputs would fix the problem. But it gets rid of those default localized names, and architecturally, removing a bunch of unnecessary work from Comfy's creation/load process is probably a good thing.

I found this other project that shows a streamlined example of how to do dynamic inputs, and I poked at it for a few minutes just to prove that most of that code works with minimal changes even if I add a static parameter.
https://github.com/cozy-comfyui/cozy_ex_dynamic.

It might be that #2 is actually straightforward, but there's enough code to trace here that I'm probably not going to look at it. I'll poke around at the first solution so I can still offer up a PR. (I also haven't seen any replies here, so I'm reluctant to spend too much more time on this.)