`dag.test(use_executor=True)` doesn't provide the `/execution` API, but all executors rely on it

[multimeric]

Apache Airflow version

main (development)

If "Other Airflow 2/3 version" selected, which one?

No response

What happened?

All executors, even as simple as the LocalExecutor try to send API requests to /execution. I'm not exactly sure which component typically provides this, maybe the API server. However, dag.test(use_executor=True) doesn't run the component that does, so you end up with a lot of '[Errno 61] Connection refused' from trying to call <Request('PATCH', 'http://localhost:8789/execution/task-instances/019aebfb-c04b-77bd-bf3c-4feb705d81ea/run')>.

As a result, I'm not able to run dag.test(use_executor=True). I've had no luck starting an API server separately either. More specifically, if you start the API server before you run dag.test(), the above error goes away, but you instead get the following:

[2025-12-05T01:03:18.586481Z] {taskinstance.py:1543} ERROR - Executor LocalExecutor(parallelism=4) reported that the task instance <TaskInstance: example.extract manual__2025-12-05T01:03:08.304291+00:00 [queued]> finished with state failed, but the task instance's state attribute is queued. Learn more: https://airflow.apache.org/docs/apache-airflow/stable/troubleshooting.html#task-state-changed-externally

I think running a real API server for a test is overkill anyway.

What you think should happen instead?

No response

How to reproduce

Try to run any workflow with dag.test(use_executor=True)

Operating System

macOS 15.6

Versions of Apache Airflow Providers

No response

Deployment

Virtualenv installation

Deployment details

No response

Anything else?

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[boring-cyborg]

Thanks for opening your first issue here! Be sure to follow the issue template! If you are willing to raise PR to address this issue please do so, no need to wait for approval.

[potiuk]

I think (@amoghrajesh @ashb ?) - that's part of the task-isolation work. I am not even sure if we want to test the dags with use-executor - because indeed that would mean some test api_server running locally and have the supervisor talk to it. Maybe it could be in-memory api and no real HTTP server?

[amoghrajesh]

I think the main use case here is for running system tests with custom executors like here: #48699

It is the best way to test a combination entirely and that's probably why we have it. Maybe a warning or a pre check that api server is running would be good

[multimeric]

The reason why I want to use an executor in my tests is because I'm relying on the task retry mechanism which I believe is implemented by the scheduler, so dag.test(use_executor=False) won't correctly perform retries.

[potiuk]

The reason why I want to use an executor in my tests is because I'm relying on the task retry mechanism which I believe is implemented by the scheduler, so dag.test(use_executor=False) won't correctly perform retries.

Maybe a good idea to implement retries with use_executor = False ?