Make Task SDK supervisor subprocess a session leader

[KushagraB424]

Under which category would you file this issue?

Airflow Core

Apache Airflow version

main

What happened and how to reproduce it?

Issue Description
In task-sdk/src/airflow/sdk/execution_time/supervisor.py, the _subprocess_main function is the entry point for the child process that runs the user's task code. There is an existing TODO comment indicating that this child process should be made a session leader.

Currently, because it is not a session leader, it remains in the same process group as the parent supervisor. This means that if a signal (like SIGINT or SIGTERM) is sent to the parent process group (for instance, by the terminal), both the parent and the child will receive it independently. This can lead to double-firing of signal handlers and race conditions during shutdown or interruption.

Steps to reproduce
N/A - This is a structural process-isolation improvement identified via an existing TODO in task-sdk/src/airflow/sdk/execution_time/supervisor.py. I have already implemented the fix and will be raising a PR shortly.

What you think should happen instead?

The child process should be made a session leader immediately upon startup to isolate it into its own process group. This ensures that signals are handled explicitly through the supervisor's lifecycle management rather than being automatically broadcasted to both processes.

We can achieve this by calling os.setsid() (guarded by hasattr(os, "setsid") and a try-except block for cross-platform compatibility) right after the subprocess starts.

Operating System

Any

Deployment

None

Apache Airflow Provider(s)

No response

Versions of Apache Airflow Providers

Not Applicable

Official Helm Chart version

Not Applicable

Kubernetes Version

No response

Helm Chart configuration

Not Applicable

Docker Image customizations

Not Applicable

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

[kaxil]

The double-firing this describes is already handled: _reset_signals() at the top of _fork_main resets SIGINT/SIGTERM/SIGUSR2 to SIG_DFL in the child, so inherited handlers can't fire twice. The child receiving group signals directly after that is intentional -- it's how the task subprocess gets SIGTERM on container stop when dumb-init runs with DUMB_INIT_SETSID=1 (the official image default).

The TODO comment itself is stale; #65738 removes it and adds the reviewed version of the process-group change (os.setpgid(0, 0) scoped to task execution, paired with os.killpg). Closing as not planned.