Add triggering_user_name to DagRunProtocol interface

[dheerajturaga]

Enable tasks running in isolated environments to access the username
that triggered a DAG run without requiring direct database access.

Changes:

• Add triggering_user_name field to DagRunProtocol interface
• Update task-sdk DagRun data model to include triggering_user_name
• Update execution API DagRun model to include triggering_user_name
• Ensure field flows from database through API to task context

This allows developers to identify DAG run triggers from within task
code using the existing DagRunProtocol interface.

deffind_owner(dag_run: DagRunProtocol) ->str:
""" Extract the owner information from the DAG run. Args: dag_run: The DAG run protocol object containing run information Returns: str: Information about who triggered the DAG run """triggering_user=dag_run.triggering_user_nameiftriggering_user:
returnf"DAG was triggered by user: {triggering_user}"else:
return"DAG was triggered automatically (no user specified)"

[dheerajturaga]

cc: @jscheffl

[jscheffl]

Looks reasonable for me.

[dheerajturaga]

Cc: @kaxil I would like this in 3.1.1

[jscheffl]

Adding backport label but leave the decision to @kaxil if OK to backport as not a classic bug fix but a minor feature

[kaxil]

Cc: @kaxil I would like this in 3.1.1

https://github.com/apache/airflow/blob/main/contributing-docs/19_execution_api_versioning.rst -- We would need to add a Cadwyn migration.

Check examples in https://github.com/apache/airflow/tree/main/airflow-core/src/airflow/api_fastapi/execution_api/versions

[dheerajturaga]

cc: @kaxil this looks good?

[kaxil]

1 test suggestion otherwise lgtm

[github-actions]

Backport successfully created: v3-1-test

Status	Branch	Result
✅	v3-1-test

[dheerajturaga]

@kaxil , the milestone needs to be 3.1.1? This seems to be missing from 3.1.1rc1

[kaxil]

Didn't include it in 3.1.1 since it isn't a bugfix

[dheerajturaga]

Didn't include it in 3.1.1 since it isn't a bugfix

Can we include it? I remember you mentioned it shouldn't be a problem. especially now since we have cadwyn migration added aswell. Its a significant item for our workflows given there's no way in airflow3 to identify dagrun owner in the task

[kaxil]

Didn't include it in 3.1.1 since it isn't a bugfix

Can we include it? I remember you mentioned it shouldn't be a problem. especially now since we have cadwyn migration added aswell. Its a significant item for our workflows given there's no way in airflow3 to identify dagrun owner in the task

I did but unfortunately couldn't justify it as a bugfix when cherry-picking so had changed the milestone attached to it. I really do not want to risk 3.1.1 since there were a couple of high-priority bugfixes in it.

[kaxil]

Ok looking back and tracking it -- Fix tasks unable to access triggering_user_name` is a better PR title and is a bugfix since technically it indeed was one of the use-case for #51738 .

We will have it in 3.1.2

[kaxil]

Has been cherry-picked as faeb1bf

[dheerajturaga]

Enable tasks running in isolated environments to access the username
that triggered a DAG run without requiring direct database access.

Changes:

• Add triggering_user_name field to DagRunProtocol interface
• Update task-sdk DagRun data model to include triggering_user_name
• Update execution API DagRun model to include triggering_user_name
• Ensure field flows from database through API to task context

This allows developers to identify DAG run triggers from within task
code using the existing DagRunProtocol interface.

deffind_owner(dag_run: DagRunProtocol) ->str:
""" Extract the owner information from the DAG run. Args: dag_run: The DAG run protocol object containing run information Returns: str: Information about who triggered the DAG run """triggering_user=dag_run.triggering_user_nameiftriggering_user:
returnf"DAG was triggered by user: {triggering_user}"else:
return"DAG was triggered automatically (no user specified)"

[dheerajturaga]

cc: @jscheffl

[jscheffl]

Looks reasonable for me.

[dheerajturaga]

Cc: @kaxil I would like this in 3.1.1

[jscheffl]

Adding backport label but leave the decision to @kaxil if OK to backport as not a classic bug fix but a minor feature

[kaxil]

Cc: @kaxil I would like this in 3.1.1

https://github.com/apache/airflow/blob/main/contributing-docs/19_execution_api_versioning.rst -- We would need to add a Cadwyn migration.

Check examples in https://github.com/apache/airflow/tree/main/airflow-core/src/airflow/api_fastapi/execution_api/versions

[dheerajturaga]

cc: @kaxil this looks good?

[kaxil]

1 test suggestion otherwise lgtm

[github-actions]

Backport successfully created: v3-1-test

Status	Branch	Result
✅	v3-1-test

[dheerajturaga]

@kaxil , the milestone needs to be 3.1.1? This seems to be missing from 3.1.1rc1

[kaxil]

Didn't include it in 3.1.1 since it isn't a bugfix

[dheerajturaga]

Didn't include it in 3.1.1 since it isn't a bugfix

Can we include it? I remember you mentioned it shouldn't be a problem. especially now since we have cadwyn migration added aswell. Its a significant item for our workflows given there's no way in airflow3 to identify dagrun owner in the task

[kaxil]

Didn't include it in 3.1.1 since it isn't a bugfix

Can we include it? I remember you mentioned it shouldn't be a problem. especially now since we have cadwyn migration added aswell. Its a significant item for our workflows given there's no way in airflow3 to identify dagrun owner in the task

I did but unfortunately couldn't justify it as a bugfix when cherry-picking so had changed the milestone attached to it. I really do not want to risk 3.1.1 since there were a couple of high-priority bugfixes in it.

[kaxil]

Ok looking back and tracking it -- Fix tasks unable to access triggering_user_name` is a better PR title and is a bugfix since technically it indeed was one of the use-case for #51738 .

We will have it in 3.1.2

[kaxil]

Has been cherry-picked as faeb1bf

[dheerajturaga]

Enable tasks running in isolated environments to access the username
that triggered a DAG run without requiring direct database access.

Changes:

• Add triggering_user_name field to DagRunProtocol interface
• Update task-sdk DagRun data model to include triggering_user_name
• Update execution API DagRun model to include triggering_user_name
• Ensure field flows from database through API to task context

This allows developers to identify DAG run triggers from within task
code using the existing DagRunProtocol interface.

deffind_owner(dag_run: DagRunProtocol) ->str:
""" Extract the owner information from the DAG run. Args: dag_run: The DAG run protocol object containing run information Returns: str: Information about who triggered the DAG run """triggering_user=dag_run.triggering_user_nameiftriggering_user:
returnf"DAG was triggered by user: {triggering_user}"else:
return"DAG was triggered automatically (no user specified)"

[dheerajturaga]

cc: @jscheffl

[jscheffl]

Looks reasonable for me.

[dheerajturaga]

Cc: @kaxil I would like this in 3.1.1

[jscheffl]

Adding backport label but leave the decision to @kaxil if OK to backport as not a classic bug fix but a minor feature

[kaxil]

Cc: @kaxil I would like this in 3.1.1

https://github.com/apache/airflow/blob/main/contributing-docs/19_execution_api_versioning.rst -- We would need to add a Cadwyn migration.

Check examples in https://github.com/apache/airflow/tree/main/airflow-core/src/airflow/api_fastapi/execution_api/versions

[dheerajturaga]

cc: @kaxil this looks good?

[kaxil]

1 test suggestion otherwise lgtm

[github-actions]

Backport successfully created: v3-1-test

Status	Branch	Result
✅	v3-1-test

[dheerajturaga]

@kaxil , the milestone needs to be 3.1.1? This seems to be missing from 3.1.1rc1

[kaxil]

Didn't include it in 3.1.1 since it isn't a bugfix

[dheerajturaga]

Didn't include it in 3.1.1 since it isn't a bugfix

Can we include it? I remember you mentioned it shouldn't be a problem. especially now since we have cadwyn migration added aswell. Its a significant item for our workflows given there's no way in airflow3 to identify dagrun owner in the task

[kaxil]

Didn't include it in 3.1.1 since it isn't a bugfix

Can we include it? I remember you mentioned it shouldn't be a problem. especially now since we have cadwyn migration added aswell. Its a significant item for our workflows given there's no way in airflow3 to identify dagrun owner in the task

I did but unfortunately couldn't justify it as a bugfix when cherry-picking so had changed the milestone attached to it. I really do not want to risk 3.1.1 since there were a couple of high-priority bugfixes in it.

[kaxil]

Ok looking back and tracking it -- Fix tasks unable to access triggering_user_name` is a better PR title and is a bugfix since technically it indeed was one of the use-case for #51738 .

We will have it in 3.1.2

[kaxil]

Has been cherry-picked as faeb1bf

[dheerajturaga]

Enable tasks running in isolated environments to access the username
that triggered a DAG run without requiring direct database access.

Changes:

• Add triggering_user_name field to DagRunProtocol interface
• Update task-sdk DagRun data model to include triggering_user_name
• Update execution API DagRun model to include triggering_user_name
• Ensure field flows from database through API to task context

This allows developers to identify DAG run triggers from within task
code using the existing DagRunProtocol interface.

deffind_owner(dag_run: DagRunProtocol) ->str:
""" Extract the owner information from the DAG run. Args: dag_run: The DAG run protocol object containing run information Returns: str: Information about who triggered the DAG run """triggering_user=dag_run.triggering_user_nameiftriggering_user:
returnf"DAG was triggered by user: {triggering_user}"else:
return"DAG was triggered automatically (no user specified)"

[dheerajturaga]

cc: @jscheffl

[jscheffl]

Looks reasonable for me.

[dheerajturaga]

Cc: @kaxil I would like this in 3.1.1

[jscheffl]

Adding backport label but leave the decision to @kaxil if OK to backport as not a classic bug fix but a minor feature

[kaxil]

Cc: @kaxil I would like this in 3.1.1

https://github.com/apache/airflow/blob/main/contributing-docs/19_execution_api_versioning.rst -- We would need to add a Cadwyn migration.

Check examples in https://github.com/apache/airflow/tree/main/airflow-core/src/airflow/api_fastapi/execution_api/versions

[dheerajturaga]

cc: @kaxil this looks good?

[kaxil]

1 test suggestion otherwise lgtm

[github-actions]

Backport successfully created: v3-1-test

Status	Branch	Result
✅	v3-1-test

[dheerajturaga]

@kaxil , the milestone needs to be 3.1.1? This seems to be missing from 3.1.1rc1

[kaxil]

Didn't include it in 3.1.1 since it isn't a bugfix

[dheerajturaga]

Didn't include it in 3.1.1 since it isn't a bugfix

Can we include it? I remember you mentioned it shouldn't be a problem. especially now since we have cadwyn migration added aswell. Its a significant item for our workflows given there's no way in airflow3 to identify dagrun owner in the task

[kaxil]

Didn't include it in 3.1.1 since it isn't a bugfix

Can we include it? I remember you mentioned it shouldn't be a problem. especially now since we have cadwyn migration added aswell. Its a significant item for our workflows given there's no way in airflow3 to identify dagrun owner in the task

I did but unfortunately couldn't justify it as a bugfix when cherry-picking so had changed the milestone attached to it. I really do not want to risk 3.1.1 since there were a couple of high-priority bugfixes in it.

[kaxil]

Ok looking back and tracking it -- Fix tasks unable to access triggering_user_name` is a better PR title and is a bugfix since technically it indeed was one of the use-case for #51738 .

We will have it in 3.1.2

[kaxil]

Has been cherry-picked as faeb1bf

[dheerajturaga]

Enable tasks running in isolated environments to access the username
that triggered a DAG run without requiring direct database access.

Changes:

• Add triggering_user_name field to DagRunProtocol interface
• Update task-sdk DagRun data model to include triggering_user_name
• Update execution API DagRun model to include triggering_user_name
• Ensure field flows from database through API to task context

This allows developers to identify DAG run triggers from within task
code using the existing DagRunProtocol interface.

deffind_owner(dag_run: DagRunProtocol) ->str:
""" Extract the owner information from the DAG run. Args: dag_run: The DAG run protocol object containing run information Returns: str: Information about who triggered the DAG run """triggering_user=dag_run.triggering_user_nameiftriggering_user:
returnf"DAG was triggered by user: {triggering_user}"else:
return"DAG was triggered automatically (no user specified)"

[dheerajturaga]

cc: @jscheffl

[jscheffl]

Looks reasonable for me.

[dheerajturaga]

Cc: @kaxil I would like this in 3.1.1

[jscheffl]

Adding backport label but leave the decision to @kaxil if OK to backport as not a classic bug fix but a minor feature

[kaxil]

Cc: @kaxil I would like this in 3.1.1

https://github.com/apache/airflow/blob/main/contributing-docs/19_execution_api_versioning.rst -- We would need to add a Cadwyn migration.

Check examples in https://github.com/apache/airflow/tree/main/airflow-core/src/airflow/api_fastapi/execution_api/versions

[dheerajturaga]

cc: @kaxil this looks good?

[kaxil]

1 test suggestion otherwise lgtm

[github-actions]

Backport successfully created: v3-1-test

Status	Branch	Result
✅	v3-1-test

[dheerajturaga]

@kaxil , the milestone needs to be 3.1.1? This seems to be missing from 3.1.1rc1

[kaxil]

Didn't include it in 3.1.1 since it isn't a bugfix

[dheerajturaga]

Didn't include it in 3.1.1 since it isn't a bugfix

Can we include it? I remember you mentioned it shouldn't be a problem. especially now since we have cadwyn migration added aswell. Its a significant item for our workflows given there's no way in airflow3 to identify dagrun owner in the task

[kaxil]

Didn't include it in 3.1.1 since it isn't a bugfix

Can we include it? I remember you mentioned it shouldn't be a problem. especially now since we have cadwyn migration added aswell. Its a significant item for our workflows given there's no way in airflow3 to identify dagrun owner in the task

I did but unfortunately couldn't justify it as a bugfix when cherry-picking so had changed the milestone attached to it. I really do not want to risk 3.1.1 since there were a couple of high-priority bugfixes in it.

[kaxil]

Ok looking back and tracking it -- Fix tasks unable to access triggering_user_name` is a better PR title and is a bugfix since technically it indeed was one of the use-case for #51738 .

We will have it in 3.1.2

[kaxil]

Has been cherry-picked as faeb1bf

[dheerajturaga]

Enable tasks running in isolated environments to access the username
that triggered a DAG run without requiring direct database access.

Changes:

• Add triggering_user_name field to DagRunProtocol interface
• Update task-sdk DagRun data model to include triggering_user_name
• Update execution API DagRun model to include triggering_user_name
• Ensure field flows from database through API to task context

This allows developers to identify DAG run triggers from within task
code using the existing DagRunProtocol interface.

deffind_owner(dag_run: DagRunProtocol) ->str:
""" Extract the owner information from the DAG run. Args: dag_run: The DAG run protocol object containing run information Returns: str: Information about who triggered the DAG run """triggering_user=dag_run.triggering_user_nameiftriggering_user:
returnf"DAG was triggered by user: {triggering_user}"else:
return"DAG was triggered automatically (no user specified)"

[dheerajturaga]

cc: @jscheffl

[jscheffl]

Looks reasonable for me.

[dheerajturaga]

Cc: @kaxil I would like this in 3.1.1

[jscheffl]

Adding backport label but leave the decision to @kaxil if OK to backport as not a classic bug fix but a minor feature

[kaxil]

Cc: @kaxil I would like this in 3.1.1

https://github.com/apache/airflow/blob/main/contributing-docs/19_execution_api_versioning.rst -- We would need to add a Cadwyn migration.

Check examples in https://github.com/apache/airflow/tree/main/airflow-core/src/airflow/api_fastapi/execution_api/versions

[dheerajturaga]

cc: @kaxil this looks good?

[kaxil]

1 test suggestion otherwise lgtm

[github-actions]

Backport successfully created: v3-1-test

Status	Branch	Result
✅	v3-1-test

[dheerajturaga]

@kaxil , the milestone needs to be 3.1.1? This seems to be missing from 3.1.1rc1

[kaxil]

Didn't include it in 3.1.1 since it isn't a bugfix

[dheerajturaga]

Didn't include it in 3.1.1 since it isn't a bugfix

Can we include it? I remember you mentioned it shouldn't be a problem. especially now since we have cadwyn migration added aswell. Its a significant item for our workflows given there's no way in airflow3 to identify dagrun owner in the task

[kaxil]

Didn't include it in 3.1.1 since it isn't a bugfix

Can we include it? I remember you mentioned it shouldn't be a problem. especially now since we have cadwyn migration added aswell. Its a significant item for our workflows given there's no way in airflow3 to identify dagrun owner in the task

I did but unfortunately couldn't justify it as a bugfix when cherry-picking so had changed the milestone attached to it. I really do not want to risk 3.1.1 since there were a couple of high-priority bugfixes in it.

[kaxil]

Ok looking back and tracking it -- Fix tasks unable to access triggering_user_name` is a better PR title and is a bugfix since technically it indeed was one of the use-case for #51738 .

We will have it in 3.1.2

[kaxil]

Has been cherry-picked as faeb1bf

[dheerajturaga]

Enable tasks running in isolated environments to access the username
that triggered a DAG run without requiring direct database access.

Changes:

• Add triggering_user_name field to DagRunProtocol interface
• Update task-sdk DagRun data model to include triggering_user_name
• Update execution API DagRun model to include triggering_user_name
• Ensure field flows from database through API to task context

This allows developers to identify DAG run triggers from within task
code using the existing DagRunProtocol interface.

deffind_owner(dag_run: DagRunProtocol) ->str:
""" Extract the owner information from the DAG run. Args: dag_run: The DAG run protocol object containing run information Returns: str: Information about who triggered the DAG run """triggering_user=dag_run.triggering_user_nameiftriggering_user:
returnf"DAG was triggered by user: {triggering_user}"else:
return"DAG was triggered automatically (no user specified)"

[dheerajturaga]

cc: @jscheffl

[jscheffl]

Looks reasonable for me.

[dheerajturaga]

Cc: @kaxil I would like this in 3.1.1

[jscheffl]

Adding backport label but leave the decision to @kaxil if OK to backport as not a classic bug fix but a minor feature

[kaxil]

Cc: @kaxil I would like this in 3.1.1

https://github.com/apache/airflow/blob/main/contributing-docs/19_execution_api_versioning.rst -- We would need to add a Cadwyn migration.

Check examples in https://github.com/apache/airflow/tree/main/airflow-core/src/airflow/api_fastapi/execution_api/versions

[dheerajturaga]

cc: @kaxil this looks good?

[kaxil]

1 test suggestion otherwise lgtm

[github-actions]

Backport successfully created: v3-1-test

Status	Branch	Result
✅	v3-1-test

[dheerajturaga]

@kaxil , the milestone needs to be 3.1.1? This seems to be missing from 3.1.1rc1

[kaxil]

Didn't include it in 3.1.1 since it isn't a bugfix

[dheerajturaga]

Didn't include it in 3.1.1 since it isn't a bugfix

Can we include it? I remember you mentioned it shouldn't be a problem. especially now since we have cadwyn migration added aswell. Its a significant item for our workflows given there's no way in airflow3 to identify dagrun owner in the task

[kaxil]

Didn't include it in 3.1.1 since it isn't a bugfix

Can we include it? I remember you mentioned it shouldn't be a problem. especially now since we have cadwyn migration added aswell. Its a significant item for our workflows given there's no way in airflow3 to identify dagrun owner in the task

I did but unfortunately couldn't justify it as a bugfix when cherry-picking so had changed the milestone attached to it. I really do not want to risk 3.1.1 since there were a couple of high-priority bugfixes in it.

[kaxil]

Ok looking back and tracking it -- Fix tasks unable to access triggering_user_name` is a better PR title and is a bugfix since technically it indeed was one of the use-case for #51738 .

We will have it in 3.1.2

[kaxil]

Has been cherry-picked as faeb1bf

[dheerajturaga]

Enable tasks running in isolated environments to access the username
that triggered a DAG run without requiring direct database access.

Changes:

• Add triggering_user_name field to DagRunProtocol interface
• Update task-sdk DagRun data model to include triggering_user_name
• Update execution API DagRun model to include triggering_user_name
• Ensure field flows from database through API to task context

This allows developers to identify DAG run triggers from within task
code using the existing DagRunProtocol interface.

deffind_owner(dag_run: DagRunProtocol) ->str:
""" Extract the owner information from the DAG run. Args: dag_run: The DAG run protocol object containing run information Returns: str: Information about who triggered the DAG run """triggering_user=dag_run.triggering_user_nameiftriggering_user:
returnf"DAG was triggered by user: {triggering_user}"else:
return"DAG was triggered automatically (no user specified)"

[dheerajturaga]

cc: @jscheffl

[jscheffl]

Looks reasonable for me.

[dheerajturaga]

Cc: @kaxil I would like this in 3.1.1

[jscheffl]

Adding backport label but leave the decision to @kaxil if OK to backport as not a classic bug fix but a minor feature

[kaxil]

Cc: @kaxil I would like this in 3.1.1

https://github.com/apache/airflow/blob/main/contributing-docs/19_execution_api_versioning.rst -- We would need to add a Cadwyn migration.

Check examples in https://github.com/apache/airflow/tree/main/airflow-core/src/airflow/api_fastapi/execution_api/versions

[dheerajturaga]

cc: @kaxil this looks good?

[kaxil]

1 test suggestion otherwise lgtm

[github-actions]

Backport successfully created: v3-1-test

Status	Branch	Result
✅	v3-1-test

[dheerajturaga]

@kaxil , the milestone needs to be 3.1.1? This seems to be missing from 3.1.1rc1

[kaxil]

Didn't include it in 3.1.1 since it isn't a bugfix

[dheerajturaga]

Didn't include it in 3.1.1 since it isn't a bugfix

Can we include it? I remember you mentioned it shouldn't be a problem. especially now since we have cadwyn migration added aswell. Its a significant item for our workflows given there's no way in airflow3 to identify dagrun owner in the task

[kaxil]

Didn't include it in 3.1.1 since it isn't a bugfix

Can we include it? I remember you mentioned it shouldn't be a problem. especially now since we have cadwyn migration added aswell. Its a significant item for our workflows given there's no way in airflow3 to identify dagrun owner in the task

I did but unfortunately couldn't justify it as a bugfix when cherry-picking so had changed the milestone attached to it. I really do not want to risk 3.1.1 since there were a couple of high-priority bugfixes in it.

[kaxil]

Ok looking back and tracking it -- Fix tasks unable to access triggering_user_name` is a better PR title and is a bugfix since technically it indeed was one of the use-case for #51738 .

We will have it in 3.1.2

[kaxil]

Has been cherry-picked as faeb1bf