-
Notifications
You must be signed in to change notification settings - Fork 376
Fix cyclic prototype errors with subgraphNodes #5637
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
Conversation
🎭 Playwright Test Results⏰ Completed at: 09/18/2025, 07:29:48 PM UTC 📈 Summary
📊 Test Reports by Browser
🎉 Click on the links above to view detailed test results for each browser configuration. |
The link has not yet been created at the time of this call, but the target slot was helpfully already being passed as an input and was simply ignored.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤞🏻
(I still don't think prototype setting is ever the right move) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Wait to merge this until 1.28 is released, so we can backport onto 1.27 |
@AustinMroz Backport to Please manually cherry-pick commit Conflicting files
|
@AustinMroz I can do the cherry pick |
To accomplish this, it pulls WidgetLocator information from the node owning the widget. This `node` property does not exist on all IBaseWidget. `toConcrete` was used to instead have a BaseWidget which is guaranteed to have a node property. The issue that was missed, is that a widget which lacks this information (such as most implemented by custom nodes) sets the node value to the argument which was passed. Here that is the reference to the subgraph node. Sometimes, this `#setWidget` call is made multiple times, and when this occurs, the `input.widget` has itself set as the protoyep, throwing an error. This is resolved by instead taking an additional input which is unambiguous. For reference, this is a near minimal workflow using comfy_mtb that replicates the issue [cyclic.json](https://github.com/user-attachments/files/22412187/cyclic.json) Special thanks to @melMass for assistance discovering this issue. ┆Issue is synchronized with this [Notion page](https://www.notion.so/PR-5637-Fix-cyclic-prototype-errors-with-subgraphNodes-2726d73d365081fea356f5197e4c2b42) by [Unito](https://www.unito.io)
To accomplish this, it pulls WidgetLocator information from the node owning the widget. This `node` property does not exist on all IBaseWidget. `toConcrete` was used to instead have a BaseWidget which is guaranteed to have a node property. The issue that was missed, is that a widget which lacks this information (such as most implemented by custom nodes) sets the node value to the argument which was passed. Here that is the reference to the subgraph node. Sometimes, this `#setWidget` call is made multiple times, and when this occurs, the `input.widget` has itself set as the protoyep, throwing an error. This is resolved by instead taking an additional input which is unambiguous. For reference, this is a near minimal workflow using comfy_mtb that replicates the issue [cyclic.json](https://github.com/user-attachments/files/22412187/cyclic.json) Special thanks to @melMass for assistance discovering this issue. ┆Issue is synchronized with this [Notion page](https://www.notion.so/PR-5637-Fix-cyclic-prototype-errors-with-subgraphNodes-2726d73d365081fea356f5197e4c2b42) by [Unito](https://www.unito.io)
Cherry-pick of PR #5637: Fix cyclic prototype errors with subgraphNodes ┆Issue is synchronized with this [Notion page](https://www.notion.so/PR-5650-Hotfix-Fix-cyclic-prototype-errors-with-subgraphNodes-2736d73d365081238853d5b445d08e7f) by [Unito](https://www.unito.io) Co-authored-by: AustinMroz <[email protected]>
#5024 added support for connecting primitive nodes to subgraph inputs. To accomplish this, it pulls WidgetLocator information from the node owning the widget.
This
node
property does not exist on all IBaseWidget.toConcrete
was used to instead have a BaseWidget which is guaranteed to have a node property. The issue that was missed, is that a widget which lacks this information (such as most implemented by custom nodes) sets the node value to the argument which was passed. Here that is the reference to the subgraph node. Sometimes, this#setWidget
call is made multiple times, and when this occurs, theinput.widget
has itself set as the protoyep, throwing an error.This is resolved by instead taking an additional input which is unambiguous.
For reference, this is a near minimal workflow using comfy_mtb that replicates the issue
cyclic.json
Special thanks to @melMass for assistance discovering this issue.
┆Issue is synchronized with this Notion page by Unito