-
Notifications
You must be signed in to change notification settings - Fork 107
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
Remove redundant dependency cycle while parsing forms #520
Remove redundant dependency cycle while parsing forms #520
Conversation
Note that this breaks the tests because the check at finalizeTriggerables allows for self-references. We will fix this using the tests as the baseline in the next commits
…fs while finalizing the DAG
Before this change we could ignore them because there was a cycle check before finalizing the DAG. Actually, the changed lines would be redundant
I'm creating this PR as a draft because we will sequence changes related to the DAG in a specific way, and this one comes after other stuff gets merged. This will probably require some degree of rebasing, but it feels important to be able to explore this change in isolation to advance faster by addressing things in parallel. |
It's also more comprehensive than the check we're removing here
Codecov Report
@@ Coverage Diff @@
## master #520 +/- ##
============================================
- Coverage 53.01% 52.97% -0.05%
+ Complexity 3104 3096 -8
============================================
Files 242 242
Lines 13388 13338 -50
Branches 2581 2569 -12
============================================
- Hits 7098 7066 -32
+ Misses 5455 5438 -17
+ Partials 835 834 -1
Continue to review full report at Codecov.
|
Close in favor of #526 |
This PR removes a duplicated(redundant) cycles check that was done when finalizing the triggerable DAG during form parsing.
What has been done to verify that this works as intended?
Added automated regression tests to ensure no cycles are allowed.
Why is this the best possible solution? Were any other approaches considered?
We could always leave the other cycles check and remove the one at
finalizeTriggerables
but it feels like this should be coupled to the finalization method to avoid accidentally missing to call the cycles check method.How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
The only visible changes should be that now the exception class and error message has changed.
Do we need any specific form for testing your changes? If so, please attach one.
Nope.
Does this change require updates to documentation? If so, please file an issue here and include the link below.
Nope.