-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
fix(ui): control adapter errors #5953
Conversation
There wasn't enough validation of control adapters during graph building. It would be possible for a graph to be built with empty collect node, causing an error. Addressed with an extra check. This should never happen in practice, because the invoke button should be disabled if an invalid CA is active.
The graph builders used awaited functions within `Array.prototype.forEach` loops. This doesn't do what you'd think. This caused graphs to be enqueued before they were fully constructed. Changed to `for..of` loops to fix this.
Until recently, this had a different shape than the ModelMetadataField. They are now the same, so we can re-use the ModelIdentifierField.
We can also totally remove the fetch logic because we store the same model data in state now.
I realized we can simplify things a bit more and followed this PR up with #5954. Since the changes are related, I just merged that PR into this one. Notes from that PR:
|
What type of PR is this? (check all applicable)
Have you discussed this change with the InvokeAI team?
Description
Fix two failure modes for control adapter graph creation:
await
within aforEach
loop, causing a race conditionRelated Tickets & Documents
I saw a post on discord but cannot find it now.
QA Instructions, Screenshots, Recordings
Control adapters should work
Merge Plan
This PR can be merged when approved