You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add UnitesStrategyEnum and integrate into NodeTemplate validation (#328)
* Add UnitesStrategyEnum and integrate into NodeTemplate validation
- Introduced UnitesStrategyEnum to define strategies for unites: ALL_SUCCESS and ALL_DONE.
- Updated NodeTemplate to include a strategy field, enhancing the model's validation capabilities.
- Modified the check_unites_satisfied function in create_next_states.py to incorporate the new strategy logic for state satisfaction checks, improving the handling of unites conditions.
* Update .codespellignorewords to include 'Kusto' and 'NotIn'
- Added 'Kusto' and 'NotIn' to the list of ignored words for codespell, improving spell-checking accuracy in the project.
* uv run ruff check --fix
* Update strategy field in Unites model to have a default value
- Changed the `strategy` field in the `Unites` model to use a default value of `UnitesStrategyEnum.ALL_SUCCESS`, enhancing the model's usability by providing a predefined strategy option.
* Add tests for ALL_DONE strategy in check_unites_satisfied function
- Introduced two new test cases to validate the behavior of the check_unites_satisfied function when using the ALL_DONE strategy.
- The first test checks for pending states, asserting that the result is False.
- The second test verifies the absence of pending states, asserting that the result is True.
- Updated the NodeTemplate model to include UnitesStrategyEnum for enhanced strategy handling.
* Add Unites Strategy documentation for ALL_SUCCESS and ALL_DONE
* Enhance documentation and logic for unites strategies
- Updated the `ALL_DONE` strategy description to include additional terminal statuses: `CANCELLED`, `NEXT_CREATED_ERROR`, and `PRUNED`, clarifying its behavior.
- Added a caution note to the `ALL_SUCCESS` strategy, highlighting potential indefinite blocking scenarios and suggesting the use of timeouts or fallback strategies.
- Refactored the `check_unites_satisfied` function to improve clarity and maintainability in state satisfaction checks for both `ALL_SUCCESS` and `ALL_DONE` strategies.
* Refactor tests in check_unites_satisfied to use find_one method
- Updated test cases in `test_create_next_states.py` to replace the use of `find` with `find_one` for better clarity and accuracy in state checks.
- Adjusted mock return values to reflect pending and non-pending states, enhancing the reliability of the tests.
* Update docs/docs/exosphere/architecture.md
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
---------
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Copy file name to clipboardExpand all lines: docs/docs/exosphere/architecture.md
+54-2Lines changed: 54 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -80,6 +80,58 @@ When a node has a `unites` configuration:
80
80
2.**State fingerprinting** ensures only one unites state is created per unique combination
81
81
3.**Dependency validation** ensures the unites node depends on the specified identifier
82
82
83
+
### Unites Strategy (Beta)
84
+
85
+
The `unites` keyword supports different strategies to control when the uniting node should execute. This feature is currently in **beta**.
86
+
87
+
#### Available Strategies
88
+
89
+
-**`ALL_SUCCESS`** (default): The uniting node executes only when all states with the specified identifier have reached `SUCCESS` status. If any state fails or is still processing, the uniting node will wait.
90
+
91
+
-**`ALL_DONE`**: The uniting node executes when all states with the specified identifier have reached any terminal status (`SUCCESS`, `ERRORED`, `CANCELLED`, `NEXT_CREATED_ERROR`, or `PRUNED`). This strategy allows the uniting node to proceed even if some states have failed.
92
+
93
+
#### Strategy Configuration
94
+
95
+
You can specify the strategy in your unites configuration:
-**`ALL_SUCCESS`**: Use when you need all parallel processes to complete successfully before proceeding. Ideal for data processing workflows where partial failures are not acceptable. **Caution**: This strategy can block indefinitely if any parallel branch never reaches a SUCCESS terminal state. Consider adding timeouts, explicit failure-to-success fallbacks, or using ALL_DONE when partial results are acceptable. Implement watchdogs or retry/timeout policies in workflows to prevent permanent blocking.
132
+
133
+
-**`ALL_DONE`**: Use when you want to proceed with partial results or when you have error handling logic in the uniting node. Useful for scenarios where you want to aggregate results from successful processes while handling failures separately.
134
+
83
135
### Unites Example
84
136
85
137
```json hl_lines="22-24"
@@ -95,15 +147,15 @@ When a node has a `unites` configuration:
0 commit comments