Skip to content

[Bug]: Should make link_fixer non-blocking (and, also update). #3796

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
rgthree opened this issue May 7, 2025 · 1 comment · May be fixed by #3805
Open

[Bug]: Should make link_fixer non-blocking (and, also update). #3796

rgthree opened this issue May 7, 2025 · 1 comment · May be fixed by #3805
Labels
Potential Bug Untriaged bug

Comments

@rgthree
Copy link

rgthree commented May 7, 2025

Frontend Version

Latest.

Expected Behavior

Corrupted workflows still try to load.

Actual Behavior

Corrupted workflows may throw an error.

Steps to Reproduce

See rgthree/rgthree-comfy#483 for example workflow.

Debug Logs

N/A

Browser Logs

N/A

Setting JSON

N/A

What browsers do you use to access the UI ?

No response

Other Information

I got a report at rgthree/rgthree-comfy#483 about the link_fixer causing an error, which confused me as I implemented it into rgthree-comfy to never block loading. Upon investigation, I found the error was coming from ComfyUI_frontend, which had pulled the rgthree-comfy code in at src/utils/linkFixer.ts

That's all well and good, but it looks like it's executing as part of the initialization and, as for the bug, throwing an error which stops the execution. This was not intended as part of rgthree-comfy, which checks for corruption after the workflow has loaded. This is because even corrupt workflows can have utility in the UI, from being nearly fully workable or just re-connecting the corrupted links, etc.

Consider updating the invocation so that it happens after the workflow is loaded so if there is an error, there's still something to show.

Also, I've re-written the fixer in response to the filed bug, so that it won't throw an error for that case, and also more cleanly separate checking for corruption from fixing it. I'd urge you to consider updating when you can. Thx

┆Issue is synchronized with this Notion page by Unito

@huchenlei
Copy link
Member

That's all well and good, but it looks like it's executing as part of the initialization and, as for the bug, throwing an error which stops the execution. This was not intended as part of rgthree-comfy, which checks for corruption after the workflow has loaded. This is because even corrupt workflows can have utility in the UI, from being nearly fully workable or just re-connecting the corrupted links, etc.

If the fix is not viable we do still load the initial graph. I think the issue is that if link fixer itself throw error due to internal issues, we need a try catch calude to prevent it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Potential Bug Untriaged bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants