Open f-rank opened 11 months ago
I believe this is the combination of 1 update we made to manage multiple Webui UIs at the same time, and a ComfyUI update.
The error in itself comes from the workflow types not being registered to the extension. The error is not supposed to appear if the workflow types are registeted properly.
As for the error that you get when dropping an image, this is probably a ComfyUI update yes.
@John-WL thanks for the elucidating explanation about the unregistered types, and the update "mismatch" situation.
Just to further clear what I stated, the drag image was in reference to an image rendered with auto1111, containing info about comfyui extension parameters.
Also, at start it also always loads the same default workflow for some reason.
Just putting it here so anyone experiencing similar problems can compare, or even elaborate.
Thanks for the added context.
Is there a reason why the comfy side-panel isn't hidden in the IFrame? I just updated everything and it doesn't show up for me (it is intended to be hidden to improve visibility).
Also, it's definitely weird that the default workflows are not loading for each workflow type on startup. I was not able to reproduce this so far.
(For loading workflows from A1111 generated images when drag and dropping, see #112)
The side-panel started popping up there like that. I update and now I am getting:
1) that seems related to specific nodes:
"[ComfyUI] Traceback (most recent call last):
File "D:\WORK\conda_envs\ComfyUI\ComfyUI_windows_portable\ComfyUI\nodes.py", line 1800, in load_custom_node
module_spec.loader.exec_module(module)
File "
2) also related to specific nodes:
"[ComfyUI] Traceback (most recent call last):
File "D:\WORK\conda_envs\ComfyUI\ComfyUI_windows_portable\ComfyUI\nodes.py", line 1800, in load_custom_node
module_spec.loader.exec_module(module)
File "
3) Related to a third different pack of nodes
"[ComfyUI] Traceback (most recent call last):
File "D:\WORK\conda_envs\ComfyUI\ComfyUI_windows_portable\ComfyUI\custom_nodes\NodeGPT\Agents\Assistant.py", line 9, in
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "D:\WORK\conda_envs\ComfyUI\ComfyUI_windows_portable\ComfyUI\nodes.py", line 1800, in load_custom_node
module_spec.loader.exec_module(module)
File "
[ComfyUI] Cannot import D:\WORK\conda_envs\ComfyUI\ComfyUI_windows_portable\ComfyUI\custom_nodes\NodeGPT module for custom nodes: No module named 'autogen'"
So there are three packs that fail, though they work under bare Comfyui. Then there's no to/from webui and that workflow loads up with the sidebar menu, same thing in full window.
I think this problem is caused by the extension not finding the venv your comfyui needs to work normally and falling back on the webui venv. Could you please share with us:
comfy
, comfy_extras
, custom_nodes
, etc.)venv
folder?if you are using a conda env, we will have to add support for that. the extension currently only supports pip venvs with the venv
directory directly inside the comfyui home folder.
Not using a conda env for comfyui, using a conda env for webui though. They just happen to both be downstream from a directory called conda_envs.
This all worked up to about a month ago. Some node groups didn't load because they were clearly looking for stuff that doesn't exist in webui conda env. Now it just loads that workflow and shows the menu bar, while showing void to and from Webui nodes when added.
I think this problem is caused by the extension not finding the venv your comfyui needs to work normally and falling back on the webui venv. Could you please share with us:
1. the path the extension uses to find comfyui (the path in the webui settings page) 2. the effective path to comfyui home (the directory that contains directories `comfy`, `comfy_extras`, `custom_nodes`, etc.) 3. does the comfyui home folder above at 2. contain a `venv` folder? 4. if it doesn't, which python environment do you usually use? it appears to be a conda env from what I gather
if you are using a conda env, we will have to add support for that. the extension currently only supports pip venvs with the
venv
directory directly inside the comfyui home folder.
I will add ../python_embeded
to the dierctories the extension checks for python. This should help a little bit if it doesn't fix.
The extension now checks for the portable python path location. After updating and making sure the dependencies of your custom nodes have been met in the portable python environment, let us know if you still run into issues using the extension.
Updated and made sure dependencies are met in the portable python env. It fixed, as you intended, the problems loading all the custom nodes that were failing to load. Still the same thing in auto webui though. Void to and from webui nodes and the bar. I better reinstall auto from scratch see if it fixes it.
Thank you for looking into it.
The extension now checks for the portable python path location. After updating and making sure the dependencies of your custom nodes have been met in the portable python environment, let us know if you still run into issues using the extension.
Alright, I'll let you reinstall from scratch. Before doing that, could you please share the entire logs? I wonder if we could be missing a critical piece of information. i.e. the entire logs from the webui starting to finishing starting with the error after one attempted generation.
https://pastebin.com/ksM0hkW8 Here is a full log from the time I start auto webui up to where I try to generate an image, based on the info I used by dragging previous generation metadata. That used the comfyui extension to apply some post-processing on an image. This is with everything updated, including your fix, that solves all the problems with the installed custom nodes dependencies. An image is produced but errors are thrown and it isn't post-processed by the extension.
Comfyui window looks like this throughout it, just like nothing was loaded from the metadata.
I'll hold out on the re-install case something comes up. I tried to remove the extension and install it back but that didn't change anything.
To clarify further, that: lib_comfyui.ipc.callback.RemoteError: '955c0d24-6a74-434c-9a97-841bb481f7b6' error is now thrown after every generation, even when the extension is set to off.
Alright, I'll let you reinstall from scratch. Before doing that, could you please share the entire logs? I wonder if we could be missing a critical piece of information. i.e. the entire logs from the webui starting to finishing starting with the error after one attempted generation.
Just to be sure, clicking on the "Reload ComfyUI interfaces (client side)" doesn't fix the problem, correct? Is there any error reported in the browser when you click on that button? Basically, the problem appears to be that the ui doesn't register the iframes with the backend for some reason.
I just pushed a small update to the reload button that may give us more information, make sure to test this on the latest version of the extension.
https://pastebin.com/7uSEvBgq this is the full console output from webui launch to pressing the Reload button, on latest update. If I then generate an image from old metadata that contained comfyui post-process stuff it adds this to the console output: https://pastebin.com/5799Y3vN
I just pushed a small update to the reload button that may give us more information, make sure to test this on the latest version of the extension.
Yes, but what about the browser console? Are there errors in the browser (not the server, but i.e. chrome or firefox) after clicking on the reload button?
https://pastebin.com/ghtMnLX6 The full browser console output after pressing the reload button
Yes, but what about the browser console? Are there errors in the browser (not the server, but i.e. chrome or firefox) after clicking on the reload button?
Thanks. I see that the browser can't find any of the js files of the extension, which is why the iframes fail to load. Now we have to figure out why the server returns 404 on them. Do you know how to locate the current js files in your browser? Normally, you can press F12 -> go to the "Debugger" tab -> open any of the ComfyUI sections on the left. This is what I see under localhost:8189/webui_scripts/sd-webui-comfyui/extensions
:
@ljleb all I got under the debugger that identifies the iframe is this:
there are other entries connecting to same port on 127.0.0.1 but they don't highlight the element. Something more specific I can provide ?
Something more specific I can provide?
For now I can't think of another piece of information that could help here. I tried to look into it a little bit with everything you shared, but to no avail so far. I think I'll need a bit more time to find a way to reproduce. I did find one or two improvements to the repo to commit but nothing that can fix this really.
I'm sorry, I unfortunately have to focus on real life for the next week at least, but I should be able to check back here after. If anyone finds a solution and wants this fixed sooner, PRs are welcome.
Maybe one last thing to try could be to toggle on/off the reverse proxy and restart fully the webui between each settings update. The reverse proxy intercepts js files and replaces some of the import paths to make comfyui js extensions work, so maybe it is related to the 404s. I'm not confident this will do anything but it's worth a try I think.
Tried the options with a full restart between updates. Nothing changes though. It's always loading the side menu and the workflow. At least the node dependencies got fixed. Thanks for looking into it.
Maybe one last thing to try could be to toggle on/off the reverse proxy and restart fully the webui between each settings update. The reverse proxy intercepts js files and replaces some of the import paths to make comfyui js extensions work, so maybe it is related to the 404s. I'm not confident this will do anything but it's worth a try I think.
Something changed after this last update. Now one of the webui's node is populated.
That's... interesting. Does it work if you temporarily disable every comfyui nodes? A quick way to do this is to use a completely new comfyui install location and then download comfyui using the extension or by manually cloning to that location.
Maybe another thing to try at this point would be a factory install of the webui + sd-webui-comfyui + comfyui in another directory to see if the problem still occurs there.
Somehow too much stuff in the updates made me miss your reply. Sorry. I think you're correct about what would fix it, makes sense, will have to eat the bullet after finishing some stuff I am doing atm. Clean Install here I go. Thanks @ljleb
That's... interesting. Does it work if you temporarily disable every comfyui nodes? A quick way to do this is to use a completely new comfyui install location and then download comfyui using the extension or by manually cloning to that location.
Maybe another thing to try at this point would be a factory install of the webui + sd-webui-comfyui + comfyui in another directory to see if the problem still occurs there.
KeyError: '2c6790ce-6b3c-42f1-84f5-3d851710a489'
raise res.error from res
File "/storage/stable-diffusion-webui/extensions/sd-webui-comfyui/lib_comfyui/ipc/callback.py", line 73, in get
res = current_callback_proxies[process_id].get(args=(function.__module__, function.__qualname__, args, kwargs))
File "/storage/stable-diffusion-webui/extensions/sd-webui-comfyui/lib_comfyui/ipc/__init__.py", line 20, in wrapper
return ComfyuiIFrameRequests.send(request='webui_serialize_graph', workflow_type=workflow_type_id)
File "/storage/stable-diffusion-webui/extensions/sd-webui-comfyui/lib_comfyui/comfyui/iframe_requests.py", line 145, in get_workflow_graph
workflow_graph = get_workflow_graph(workflow_type_id)
File "/storage/stable-diffusion-webui/extensions/sd-webui-comfyui/lib_comfyui/comfyui/iframe_requests.py", line 78, in validate_amount_of_nodes_or_throw
return function(*args, **kwargs)
File "/storage/stable-diffusion-webui/extensions/sd-webui-comfyui/lib_comfyui/ipc/__init__.py", line 41, in wrapper
ComfyuiIFrameRequests.validate_amount_of_nodes_or_throw(
File "/storage/stable-diffusion-webui/extensions/sd-webui-comfyui/lib_comfyui/comfyui/iframe_requests.py", line 121, in extend_infotext_with_comfyui_workflows
iframe_requests.extend_infotext_with_comfyui_workflows(p, self.get_tab())
File "/storage/stable-diffusion-webui/extensions/sd-webui-comfyui/scripts/comfyui.py", line 57, in postprocess_batch_list
script.postprocess_batch_list(p, pp, *script_args, **kwargs)
File "/storage/stable-diffusion-webui/modules/scripts.py", line 766, in postprocess_batch_list
Traceback (most recent call last):
The above exception was the direct cause of the following exception:
lib_comfyui.ipc.callback.RemoteError: '2c6790ce-6b3c-42f1-84f5-3d851710a489'
Also get this in UI for webui nodes
Note: im using paperspace and connecting via nginx to the paperspace
Did the PR we merged today fix part of the issue?
For the webui key error, restarting the UI (ctrl + F5) should do the job. Is that not working?
You can't expect the UI to function properly if the key error is there, you NEED the Webui key to be registered by the extension when generating an image.
On every generation, after it gets handed to the extension it borks with :
"*** Error running postprocess_batch_list: D:\WORK\conda_envs\automatic\stable-diffusion-webui\extensions\sd-webui-comfyui\scripts\comfyui.py lib_comfyui.ipc.callback.RemoteError: '1d60c3da-0985-4724-95dd-80ddd2f87fa4'
---"
and trying to add the from webui and to webui doesn't work either, the nodes appear empty. This is on latest everything really. Trying to drag an image with a comfy post-process in it results in an error. Something changed, probably in comfy that's my guess.