From 48cbf4c78f82bb155dc94cd383c0373b80de9e2b Mon Sep 17 00:00:00 2001 From: "autofix-ci[bot]" <114827586+autofix-ci[bot]@users.noreply.github.com> Date: Fri, 22 Aug 2025 10:23:06 +0000 Subject: [PATCH] [autofix.ci] apply automated fixes --- api/core/workflow/docs/WORKER_POOL_CONFIG.md | 18 ++++++++------- api/core/workflow/graph_engine/README.md | 16 +++++++------- .../core/workflow/graph_engine/README.md | 22 +++++++++---------- 3 files changed, 29 insertions(+), 27 deletions(-) diff --git a/api/core/workflow/docs/WORKER_POOL_CONFIG.md b/api/core/workflow/docs/WORKER_POOL_CONFIG.md index 12b921afa4..db4cf3b6d6 100644 --- a/api/core/workflow/docs/WORKER_POOL_CONFIG.md +++ b/api/core/workflow/docs/WORKER_POOL_CONFIG.md @@ -5,9 +5,9 @@ The GraphEngine now supports **dynamic worker pool management** to optimize performance and resource usage. Instead of a fixed 10-worker pool, the engine can: 1. **Start with optimal worker count** based on graph complexity -2. **Scale up** when workload increases -3. **Scale down** when workers are idle -4. **Respect configurable min/max limits** +1. **Scale up** when workload increases +1. **Scale down** when workers are idle +1. **Respect configurable min/max limits** ## Benefits @@ -60,7 +60,7 @@ export GRAPH_ENGINE_SCALE_DOWN_IDLE_TIME=10.0 The engine analyzes the graph structure at startup: - **Sequential graphs** (no branches): 1 worker -- **Limited parallelism** (few branches): 2 workers +- **Limited parallelism** (few branches): 2 workers - **Moderate parallelism**: 3 workers - **High parallelism** (many branches): 5 workers @@ -69,11 +69,13 @@ The engine analyzes the graph structure at startup: During execution: 1. **Scale Up** triggers when: + - Queue depth exceeds `SCALE_UP_THRESHOLD` - All workers are busy and queue has items - Not at `MAX_WORKERS` limit -2. **Scale Down** triggers when: +1. **Scale Down** triggers when: + - Worker idle for more than `SCALE_DOWN_IDLE_TIME` seconds - Above `MIN_WORKERS` limit @@ -146,11 +148,11 @@ INFO: Scaled down workers: 3 -> 2 (removed 1 idle workers) ## Best Practices 1. **Start with defaults** - They work well for most cases -2. **Monitor queue depth** - Adjust `SCALE_UP_THRESHOLD` if queues back up -3. **Consider workload patterns**: +1. **Monitor queue depth** - Adjust `SCALE_UP_THRESHOLD` if queues back up +1. **Consider workload patterns**: - Bursty: Lower `SCALE_DOWN_IDLE_TIME` - Steady: Higher `SCALE_DOWN_IDLE_TIME` -4. **Test with your workloads** - Measure and tune +1. **Test with your workloads** - Measure and tune ## Troubleshooting diff --git a/api/core/workflow/graph_engine/README.md b/api/core/workflow/graph_engine/README.md index eb8691daf3..7e5c919513 100644 --- a/api/core/workflow/graph_engine/README.md +++ b/api/core/workflow/graph_engine/README.md @@ -147,9 +147,9 @@ classDiagram ### Data Flow 1. **Commands** flow from CommandChannels → CommandProcessing → Domain -2. **Events** flow from Workers → EventHandlerRegistry → State updates -3. **Node outputs** flow from Workers → OutputRegistry → ResponseCoordinator -4. **Ready nodes** flow from GraphTraversal → StateManagement → WorkerManagement +1. **Events** flow from Workers → EventHandlerRegistry → State updates +1. **Node outputs** flow from Workers → OutputRegistry → ResponseCoordinator +1. **Ready nodes** flow from GraphTraversal → StateManagement → WorkerManagement ### Extension Points @@ -160,11 +160,11 @@ classDiagram ## Execution Flow 1. **Initialization**: GraphEngine creates all subsystems with the workflow graph -2. **Node Discovery**: Traversal components identify ready nodes -3. **Worker Execution**: Workers pull from ready queue and execute nodes -4. **Event Processing**: Dispatcher routes events to appropriate handlers -5. **State Updates**: Managers track node/edge states for next steps -6. **Completion**: Coordinator detects when all nodes are done +1. **Node Discovery**: Traversal components identify ready nodes +1. **Worker Execution**: Workers pull from ready queue and execute nodes +1. **Event Processing**: Dispatcher routes events to appropriate handlers +1. **State Updates**: Managers track node/edge states for next steps +1. **Completion**: Coordinator detects when all nodes are done ## Usage diff --git a/api/tests/unit_tests/core/workflow/graph_engine/README.md b/api/tests/unit_tests/core/workflow/graph_engine/README.md index b92a461960..bff82b3ac4 100644 --- a/api/tests/unit_tests/core/workflow/graph_engine/README.md +++ b/api/tests/unit_tests/core/workflow/graph_engine/README.md @@ -5,7 +5,7 @@ This directory contains a comprehensive testing framework for the Graph Engine, including: 1. **TableTestRunner** - Advanced table-driven test framework for workflow testing -2. **Auto-Mock System** - Powerful mocking framework for testing without external dependencies +1. **Auto-Mock System** - Powerful mocking framework for testing without external dependencies ## TableTestRunner Framework @@ -210,7 +210,7 @@ result = runner.run_test_case(test_case) The auto-mock system provides a powerful framework for testing workflows that contain nodes requiring third-party services (LLM, APIs, tools, etc.) without making actual external calls. This enables: - **Fast test execution** - No network latency or API rate limits -- **Deterministic results** - Consistent outputs for reliable testing +- **Deterministic results** - Consistent outputs for reliable testing - **Cost savings** - No API usage charges during testing - **Offline testing** - Tests can run without internet connectivity - **Error simulation** - Test error handling without triggering real failures @@ -400,11 +400,11 @@ Use `TableTestRunner` to execute test cases and validate results. ## Best Practices 1. **Use descriptive mock responses** - Make it clear in outputs that they are mocked -2. **Test both success and failure paths** - Use error simulation to test error handling -3. **Keep mock configs close to tests** - Define mocks in the same test file for clarity -4. **Use custom handlers sparingly** - Only when dynamic behavior is needed -5. **Document mock behavior** - Comment why specific mock values are chosen -6. **Validate mock accuracy** - Ensure mocks reflect real service behavior +1. **Test both success and failure paths** - Use error simulation to test error handling +1. **Keep mock configs close to tests** - Define mocks in the same test file for clarity +1. **Use custom handlers sparingly** - Only when dynamic behavior is needed +1. **Document mock behavior** - Comment why specific mock values are chosen +1. **Validate mock accuracy** - Ensure mocks reflect real service behavior ## Examples @@ -481,7 +481,7 @@ uv run pytest api/tests/unit_tests/core/workflow/graph_engine/ -n auto Potential improvements to the auto-mock system: 1. **Recording and playback** - Record real API responses for replay in tests -2. **Mock templates** - Pre-defined mock configurations for common scenarios -3. **Async support** - Better support for async node execution -4. **Mock validation** - Validate mock outputs against node schemas -5. **Performance profiling** - Built-in performance metrics for mocked workflows +1. **Mock templates** - Pre-defined mock configurations for common scenarios +1. **Async support** - Better support for async node execution +1. **Mock validation** - Validate mock outputs against node schemas +1. **Performance profiling** - Built-in performance metrics for mocked workflows