rjgoyln opened a new pull request, #72260: URL: https://github.com/apache/airflow/pull/72260
## Summary The xcom commands can only run once their Dag run has finished — a task entering RUNNING clears every XCom key under it, wiping what the test just added. The wait that enforces this gave a freshly booted PROD-image compose stack 60 seconds, and each sample forked `airflowctl auth login && airflowctl dagrun get` with its own 20 second timeout, so a slow machine got a handful of looks rather than sixty while the polling competed for CPU with the stack it was waiting on. A cold scheduler needing more than a minute to queue and run a bash task is not a failure, but the suite reported it as five: all the xcom commands share one Dag run, and `xcom delete` failed behind the misleading "XCom doesn't exist". ## Change Polling moved to the REST API and the budget to 300 seconds, overridable with `AIRFLOW_CTL_TEST_DAG_RUN_TIMEOUT`. The longer budget is for a slow stack rather than a broken one, so a rejected request still fails immediately instead of polling out the clock, and a timeout now names the Dag run and task instance states — enough to tell a run the scheduler never picked up from a task still executing. Only the first xcom command spends the budget; the rest skip after one re-check, so a run that finishes late still lets them through. ## Tests The wait was exercised against a live compose stack, where the timeout message rendered the per-task states. --- ##### Was generative AI tooling used to co-author this PR? - [X] Yes — Claude Code (Opus 5) Generated-by: Claude Code (Opus 5) following [the guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions) -- 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]
