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-1706 Make Automatic Run Type honor RunEnabled settings #9680

Merged
merged 5 commits into from
Apr 29, 2019

Conversation

reddyashish
Copy link
Contributor

@reddyashish reddyashish commented Apr 24, 2019

Purpose

This PR is to fix an issue that was introduced after merging: #9641

As per the current design, the variable "RunSettings.RunEnabled" is associated with the Run button in dynamo. When successive "RequestRun()" calls are triggered, this causes an issue because when the Run() adds a task to the scheduler, the RunEnabled flag is set to false till the execution is completed. It is then be set back to true in a different thread that triggers the "OnUpdateGraphCompleted" even upon completion of the first task. During this execution, if the "RequestRun" is triggered again by the "OnNodeModified" event, the second Run() wont be called because the RunEnabled is set to false at this state. https://github.com/reddyashish/Dynamo/blob/65dff195c657f39e82813cc38c45fd3a3695c30c/src/DynamoCore/Graph/Workspaces/HomeWorkspaceModel.cs#L337

To overcome this issue, we have used another boolean to track this and trigger the "Run()" if necessary. This is a temporary fix and should be avoided by using a separate variable that checks if the Run is enabled/disabled from external applications. Once we introduce that new variable, we can make this "RunSettings.RunEnabled" property private and not expose it outside as this keeps track of internal executions. The above solution would cause an API break, so added a TODO comment to the code to change it in 3.0. I will keep a track of this.

Declarations

Check these if you believe they are true

  • The code base 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.

Reviewers

@aparajit-pratap @QilongTang @mjkkirschner

// We will be needing a separate variable(boolean) to check for RunEnabled flag from external applications and
// not confuse it with the internal flag RunEnabled which is associated with the Run button in Dynamo.
// Make this RunSettings.RunEnabled private, introduce the new flag and remove the "executingTask" variable.
if (RunSettings.RunEnabled || executingTask)
Copy link
Contributor

Choose a reason for hiding this comment

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

should it be !executingTask?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, because this boolean tracks if the previous run is completely executed or not. In the case, where OnUpdateGraphCompleted event is not completed, we want to trigger the next runs. In the end the executing task will be set to false.

Copy link
Contributor

Choose a reason for hiding this comment

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

I see, since we are using ||, normal case it will just be dominated by RunSettings.RunEnabled which is always true. But once RunEnabled become false, run() can't be called at all

@aparajit-pratap
Copy link
Contributor

@reddyashish we need to make sure that although this fixes the regression introduced from your earlier fix, this PR still fixes the original issue raised by the C3D team: https://jira.autodesk.com/browse/DYN-1706. Can you verify?

@reddyashish
Copy link
Contributor Author

@aparajit-pratap yes, I have tested this again with Revit locally as Civil3D already has a workaround for this presently. It fixes the original issue. We also have a test case to test that workflow.

@QilongTang
Copy link
Contributor

LGTM, and I believe this is what Civil3D team expects

@reddyashish reddyashish merged commit 76c7b61 into DynamoDS:master Apr 29, 2019
mjkkirschner pushed a commit that referenced this pull request Aug 3, 2019
* Run Settings fix

* Adding manual check

* Adding test

* TODO comment for future

* Adding comments and sort Usings
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