Skip to content
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

[DYN-7943] Custom node cannot be added to its own workspace. #15783

Merged
merged 8 commits into from
Feb 7, 2025

Conversation

reddyashish
Copy link
Contributor

Purpose

https://jira.autodesk.com/browse/DYN-7943

Users were experiencing a Dynamo freeze when they try to add a custom node in its own workspace. This will cause an infinite loop and shouldn't be allowed as it is not a ideal use case.

custom node

Declarations

Check these if you believe they are true

  • The codebase is in a better state after this PR
  • Is documented according to the standards
  • The level of testing this PR includes is appropriate
  • User facing strings, if any, are extracted into *.resx files
  • All tests pass using the self-service CI.
  • Snapshot of UI changes, if any.
  • Changes to the API follow Semantic Versioning and are documented in the API Changes document.
  • This PR modifies some build requirements and the readme is updated
  • This PR contains no files larger than 50 MB

Release Notes

[DYN-7943] Custom node cannot be added to its own workspace.

Reviewers

@QilongTang @zeusongit

Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See the ticket for this pull request: https://jira.autodesk.com/browse/DYN-7943

@mjkkirschner
Copy link
Member

mjkkirschner commented Jan 27, 2025

@reddyashish - customnodes actually can be safely added to their own workspace if a user utilizes the scopeif node and properly implements the recursive base case... now, does anyone do that, I have no idea, it's really hard to get right - but perhaps existing packages should be evaluated before making this breaking change.

@QilongTang QilongTang added this to the 3.5 milestone Jan 27, 2025
@QilongTang
Copy link
Contributor

@reddyashish - customnodes actually can be safely added to their own workspace if a user utilizes the scopeif node and properly implements the recursive base case... now, does anyone do that, I have no idea, it's really hard to get right - but perhaps existing packages should be evaluated before making this breaking change.

Then maybe we change the message to, the custom node cant be safely placed into the current custom node workspace without scopeif node? It might be pretty easy to detect if there is any

@reddyashish
Copy link
Contributor Author

Thank you both. I have updated the message to let users know about using the scopeif node.

I will check if this is breaking any existing packages.

{
var nodeGuid = Guid.Parse(nodeName);

if (nodeGuid.Equals(customNodeWorkspaceModel.CustomNodeId))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think @QilongTang was suggesting that in this check you iterate all the other nodes and make sure that one of them is scopeif OR you defer this check until they try to save the .dyf.

Copy link
Member

@mjkkirschner mjkkirschner Jan 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you wanted to get really fancy you could try to determine if they have the scope if hooked up correctly or at least in a topology where it has even a remote chance of working...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it, looking into it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated the changes to look for the scopeif node in the custom node workspace and only then allow users to place the custom node in its own workspace. Modified the notification message accordingly.
As this freeze/hang happens mainly when that particular custom node instance is also present in the home workspace and is executed automatically, doing this check during saving the dyf wouldn't fix this case.

Copy link
Member

@mjkkirschner mjkkirschner Feb 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what about also switching them into manual run mode when this occurs - I think we have a notification for this already under some circumstances? Maybe when using tuneup - or at least we did that previously.

Copy link
Contributor Author

@reddyashish reddyashish Feb 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes made the change to also set the homeworkspace to manual mode, when this case arises.

Copy link

github-actions bot commented Feb 3, 2025

UI Smoke Tests

Test: success. 11 passed, 0 failed.
TestComplete Test Result
Workflow Run: UI Smoke Tests
Check: UI Smoke Tests

@reddyashish
Copy link
Contributor Author

The only failing test RemovesScriptTagsFromLoadedHtml doesn't seem related to this.

@reddyashish
Copy link
Contributor Author

@reddyashish reddyashish merged commit 7a076d8 into DynamoDS:master Feb 7, 2025
23 of 24 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants