feat: Phase 7 — Worker Boundary and Cloud-Safe Execution Profiles#2
Conversation
- WorkerBoundary: async dispatch via asyncio.create_task, status tracking - ExecutionProfile: LOCAL/CLOUD_SAFE enum, assert_provider_allowed guard - 27 new tests covering WRKR-01, WRKR-02, WRKR-03 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
… fallback Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Closes WRKR-01, WRKR-02, WRKR-03 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3d45101ac8
ℹ️ 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".
| args = parser.parse_args() | ||
|
|
||
| # Resolve execution profile from --profile flag (default: local). | ||
| profile = CLOUD_SAFE_PROFILE if args.profile == WorkerProfile.CLOUD_SAFE.value else LOCAL_PROFILE |
There was a problem hiding this comment.
Enforce the selected cloud-safe profile
When --profile cloud-safe is used with AUTOGEN_PROVIDER=gemini-cli, claude-cli, or codex-cli, the selected profile is only assigned and printed; run_blocking_chat and run_resumable_step still call create_model_client(settings) without checking or passing it, and dashboard starts the app without preserving it. Consequently, a command advertised as disabling subprocess providers still constructs and runs them.
Useful? React with 👍 / 👎.
| profile: ExecutionProfile = LOCAL_PROFILE, | ||
| ): | ||
| # Guard: reject subprocess-backed providers when the profile disallows them. | ||
| profile.assert_provider_allowed(step.provider) |
There was a problem hiding this comment.
Pass the execution profile through fallback calls
The new guard always receives LOCAL_PROFILE in production because both internal _execute_chain_step call sites omit the profile argument and no runtime path passes CLOUD_SAFE_PROFILE. Therefore, when a cloud-safe MAF run reaches a CLI fallback, the guard permits it and the subprocess is still spawned; the active profile needs to be carried through the middleware and forwarded here.
Useful? React with 👍 / 👎.
| task = asyncio.create_task(self._run(run_id, workflow)) | ||
| self._tasks[run_id] = task |
There was a problem hiding this comment.
Release completed tasks from the worker registry
Every submission stores its task in _tasks, but completed tasks are never removed and there is no cleanup method. In a long-lived HTTP worker, each run permanently grows this registry and retains a completed Task; add completion cleanup while retaining the separately tracked status.
Useful? React with 👍 / 👎.
Summary
Test plan
Generated with Claude Code