kaxil opened a new pull request, #74297: URL: https://github.com/apache/airflow/pull/74297
The sandbox guide answered "should I use this, or `KubernetesExecutor`, `KubernetesPodOperator` or code mode?" in four separate sections well down the page, and carried two overlapping lists of limitations. This reorganizes `sandbox/index.rst` around that decision: - **Opens with when to use something else**: named operations (`SQLToolset`/`HookToolset`), code mode, `KubernetesExecutor`, `KubernetesPodOperator`. - **New "Where each piece runs" section** with a mermaid diagram: only the four sandbox tools move into the sandbox; the agent loop, the LLM credential and every other toolset stay where the task runs. It also shows `sbx` on the worker host versus Modal and OpenSandbox off it, and lists the provisioning credential for each backend. - **One limitations list.** "What it cannot do" and "Limitations" are merged under the existing `sandbox-limitations` label, each item linking to where it is explained. Claims that read as universal but are backend-specific are now scoped: attaching works on Modal only, running as root is documented for Modal, and `sbx` needs KVM only on Linux. - **Real output in the quick start**: the task-log summary and the `Findings` XCom from running the investigation example on Modal against a seeded Postgres warehouse, the exact error `sbx` raises for a bare `SandboxSpec()`, and the `UsageLimitExceeded` error that one of the two captured runs hit at pydantic-ai's default 50-request limit, with how to raise it. - **Text from before Modal and OpenSandbox shipped** is updated: OpenSandbox appears where backends and credentials are listed, and code mode is no longer contrasted only with `sbx`. `concepts.rst` now links to the new placement section, and `backends.rst` gains a `sandbox-backend-sbx` label. No existing label was removed or renamed, so inbound links still resolve. The docs build and spellcheck pass. Found while capturing the output, not changed here: the `AgentOperator` docstring says `usage_limits=None` "means no enforcement", but pydantic-ai's default `request_limit=50` still applies, which is what the failed run hit. That is a one-line docstring fix for a separate PR. --- * Read the **[Pull Request Guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#pull-request-guidelines)** for more information. Note: commit author/co-author name and email in commits become permanently public when merged. * For fundamental code changes, an Airflow Improvement Proposal ([AIP](https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvement+Proposals)) is needed. * When adding dependency, check compliance with the [ASF 3rd Party License Policy](https://www.apache.org/legal/resolved.html#category-x). * For significant user-facing changes create newsfragment: `{pr_number}.significant.rst`, in [airflow-core/newsfragments](https://github.com/apache/airflow/tree/main/airflow-core/newsfragments). You can add this file in a follow-up commit after the PR is created so you know the PR number. -- 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]
