kaxil opened a new pull request, #74708: URL: https://github.com/apache/airflow/pull/74708
The common.ai docs describe `fallback_conn_ids` and `durable=True` on separate pages, but nothing tells a platform owner what an agent task actually survives. This adds a "Recovering from failures" page under Reliability and operations. A table gives, per failure (provider error or timeout, whole chain down, worker lost or `execution_timeout`), the setting that handles it and whether the steps the agent already completed are kept, replayed or run again. A new example Dag combines the two settings, and the page ends with what neither covers. The claim most likely to surprise a reviewer is that a failover continues an agent run rather than restarting it. `FallbackModel` fails over per model request, and pydantic-ai sends the run's whole message history with every request, so the standby receives every tool result and no tool runs again. This was checked against real models (OpenAI `gpt-5-mini` and Anthropic `claude-sonnet-5`), with the primary made to fail after a fixed number of requests: | Scenario | Result | |---|---| | OpenAI answers two steps, then fails | Claude's first request carried both tool results; each tool ran once | | Claude, with thinking on, answers two steps, then fails | OpenAI continued from Claude's history; each tool ran once | | `durable=True`, whole chain fails on attempt 1 | Attempt 2 replayed the step OpenAI answered, sent no OpenAI request, finished on Claude | | Same, with the chain reordered between attempts | Nothing replayed; the tool ran again | The last row is why the page warns that editing `fallback_conn_ids` between attempts discards the journal: the model in a step's fingerprint is the whole chain. The log block on the page comes from `airflow dags test` of the new example with the primary pointed at a port nothing listens on. Two corrections to existing pages ride along, because the new page links to them. `provider_fallback.rst` and `retry_policies.rst` said a 30-second timeout across three connections is a 90-second worst case; the OpenAI and Anthropic SDKs retry a timed-out request twice, so it is up to 270 seconds. `provider_fallback.rst` also said a malformed prompt costs "N timeouts"; a 400 comes back at once and neither SDK retries it. --- * 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]
