zozo123 commented on issue #68845: URL: https://github.com/apache/airflow/issues/68845#issuecomment-4965954165
Scope update after deeper review and maintainer feedback: PR #68847 no longer implements the `SandboxExecutor` originally described by this issue. It now proposes a narrower `SandboxToolset` in `common.ai` for executing model-generated Python in an isolated sandbox. We now see four separate layers: - **Monty code mode:** restricted orchestration code invoking registered tools. - **SandboxToolset:** full model-generated Python executed in a separate sandbox. - **Future SandboxOperator:** an author-defined remote command/job with files and artifacts. - **Future SandboxExecutor:** the complete Airflow `ExecuteTask` workload running remotely. These are complementary, but they should not share one underspecified API. In particular, the current `create/run/destroy` backend is a code-sandbox contract, not an Airflow executor contract. A real executor must additionally support workload submission, logs, durable status, cancellation, scheduler-restart adoption, DAG bundles, scoped Execution API access, and leaked-resource reconciliation. Proposed progression: 1. Harden and land the narrowly scoped `SandboxToolset`. 2. Add backend conformance tests and vendor-owned adapters. 3. Prove artifacts, cancellation, and reconnection with a resumable/deferrable `SandboxOperator`. 4. Explore a separate third-party `SandboxExecutor` using Airflow's existing `BaseExecutor` and `ExecuteTask` interfaces. Therefore this issue remains the future executor tracker; PR #68847 should not be presented as implementing or defining that executor. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
