-
Notifications
You must be signed in to change notification settings - Fork 320
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 dangling node connection #8902
Conversation
@@ -418,7 +418,7 @@ export const useGraphStore = defineStore('graph', () => { | |||
} | |||
|
|||
function getPortNodeId(id: PortId): NodeId | undefined { | |||
return getPortPrimaryInstance(id)?.nodeId ?? db.getExpressionNodeId(id as string as Ast.AstId) | |||
return db.getExpressionNodeId(id as string as Ast.AstId) ?? getPortPrimaryInstance(id)?.nodeId |
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'm not sure about this change. If we have port instances, and they define their nodeId, they could have a reason to change it from AST?
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.
They don’t really “define” their nodeid, they use the node id derived from AST. In which case will they change it?
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.
so, the node id is derived from AST at some point, but not necessarily from Port Id. PortId is a broader than just AstId. Technically (even if it's an awful idea), some widget could create portIds which also resembles AstId, but are not bound to them. In that case, I would say the port information from PortId is more accurate than what we deduce from AstId. getExpressionNodeId
feels more like a fallback than the main route.
Of course this all is nitpicking because it will probably make no difference in real scenarios.
Pull Request Description
Fixes #8871
The issue was caused by invalid port registration. Because of the existing context switch expression (which is not visible in GUI), the port incorrectly considered itself to belong to another node. This happened because the port was only aware of the visible part of the node’s AST and considered it the whole node.
There are two fixes in this PR. Either of them fixes the issue, and they are both implemented for robustness:
nodeId
information to the widget tree, so it no longer assumes the node ID from AST.getPortNodeId
is swapped. Now we first search by AST, only then try to look up the port. It makes sense to me because the AST is a single root of truth, and we should only rely on registered ports if AST does not exist (which happens for unconnected ports).Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:
Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
./run ide build
.