Hi Mikhail,
thanks for dropping the note. I personally never had such use case and
from security perspective I assume it depends very much on the
environment if it is acceptable to change connections. In most cases you
could impact operations of other workflows if the code is bad. So at
least this would require to be a configurable option and probably you 'd
like to limit this to certain Dags/Tasks only for certain Connections.
As an alternative I'd suggest you use another connection to store
credentials to public API endpoint and then you could in a task use the
public API endpoint
https://airflow.apache.org/docs/apache-airflow/stable/stable-rest-api-ref.html#operation/patch_connection
to update the connection from a "service Dag" i a regular interval.
Jens
On 23.10.25 17:22, Mikhail Ilchenko wrote:
Hi everyone,
I would like to start a discussion about whether Airflow should support limited
modification of Connection objects from within DAGs, similar to how Variable
updates are currently allowed.
As I wrote in https://github.com/apache/airflow/discussions/53544, in Airflow
v2 I have specific DAG which
• requests API to provide access token
• updates connection
This approach was convenient for automatically refreshing temporary access
tokens and persisting them for subsequent DAG runs.
Trying to migrate to Airflow v3, however, I found out Connection objects are
effectively read-only for DAG authors — methods like set_extra and updating via
Session are no longer available.
I fully understand the reasoning behind making Connection immutable in most
cases — it helps keep the configuration consistent and safe.
However, there are real-world cases where programmatic updates of connection
metadata (like refreshed credentials, temporary URLs, or OAuth tokens) are both
safe and practical — especially when done in a controlled way.
I’d like to hear the community’s thoughts:
• Would it make sense to have a documented, limited API for updating connection
attributes from DAGs?
• Should we instead encourage another pattern and what it could be?
Best regards,
Mikhail
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
