Conversation
Introduce `create_subworker_tool` API for workers to delegate tasks to bounded child workers with explicit guardrails. The tool allows spawning subworkers through the same Desk runtime, ensuring persistence, event emission, and memory integration. Includes comprehensive documentation, usage examples, and extensive test coverage. - Add `create_subworker_tool` and `create_swarm_tool` (compatibility alias) to tools module - Implement subworker runtime with configurable budgets (max_subworkers, max_tools_per_subworker) - Add model policy enforcement and tool allowlist validation - Create detailed subworkers.md documentation covering API, behavior, and examples - Update mkdocs.yml navigation and examples.md to reference new feature - Add 6825-line test suite covering success, failure, pause, and guardrail scenarios - Ensure child runs are properly recorded in run store and error handling follows ToolResult contract
…s failed - Add `_mark_child_run_failed` helper to properly record failed child runs - Update `create_subworker_tool` to catch exceptions and mark child runs as failed - Add optional `run_id` parameter to `run` and `arun` methods for child run tracking - Add test case for runtime exceptions in subworker execution - Remove outdated subworker example documentation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: aeff35ac9f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| missing = ", ".join(missing_tools) | ||
| return ToolResult(error=f"Requested tools are not available: {missing}") | ||
|
|
||
| spawn_count += 1 |
There was a problem hiding this comment.
Count subworker budget only after successful completion
The spawn budget is consumed before the child run executes, so a failed or paused child still increments spawn_count and can exhaust max_subworkers without any successful delegation. In practice, transient adapter failures (or any non-completed child outcome) can permanently block later valid spawns for that tool instance, which makes delegation brittle under failure conditions and contradicts the documented "successful spawn attempts" behavior.
Useful? React with 👍 / 👎.
| desk.run_store.update_run( | ||
| run_id, | ||
| "failed", | ||
| None, | ||
| {"error": error}, |
There was a problem hiding this comment.
Emit terminal failure event when child run is force-failed
When child_runner.arun(...) raises, _mark_child_run_failed only updates run-store state and does not emit a run.failed event, so event-bus subscribers can observe run.started without any terminal failure signal for that child run. This breaks event-driven monitoring/workflows specifically for runtime exception paths (for example adapter crashes), even though the run status is marked failed in storage.
Useful? React with 👍 / 👎.
Summary
Testing
|
No description provided.