logical_date in TriggerDagRunOperator increment DAG version each run

[hacherix]

Under which category would you file this issue?

Airflow Core

Apache Airflow version

3.2.1

What happened and how to reproduce it?

DAG versions keep increasing with each run when using TriggerDagRunOperator.

Removing the task resolves the issue.
And setting logical_date to None in the operator also resolves the issue.
When logical_date is left to its default value the issue still occurs (seems to default to timezone.utcnow()).

    TriggerDagRunOperator(
        task_id="trigger_dag",
        trigger_dag_id="trigerred_dag_id",
        logical_date=None,
        wait_for_completion=False,
    )

The last 3 runs use a version with logical_date set to None.

What you think should happen instead?

The logical_date of TriggerDagRunOperator should not be serialized to determine a DAG version. In my opinion this defeats the purpose of DAG versionning when using TriggerDagRunOperator.

Operating System

No response

Deployment

Other Docker-based deployment

Apache Airflow Provider(s)

No response

Versions of Apache Airflow Providers

No response

Official Helm Chart version

Not Applicable

Kubernetes Version

No response

Helm Chart configuration

No response

Docker Image customizations

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.

[Abdulrehman-PIAIC80387]

Thanks for the report! I couldn't reproduce this on main — serializing a DAG with a default-logical_date TriggerDagRunOperator twice gives an identical DAG-version hash (same for logical_date=None), so no version bump.

The default isn't utcnow() — it's stored as the NOTSET sentinel and only resolved to utcnow() at execute time, so it's never serialized.

Could you retest on 3.2.2/main and share a minimal DAG + how you're seeing the version increment? That'll help narrow it down.

[hacherix]

Thanks for the swift answer!
Following your message I could not replicate it either from a clean install even with the version 3.2.1.
But looking at our metadata database, I noticed that the dag version ID was increasing with each daily run even though the source code and its hash did not change though. I did not find any other information.
I guess you can close this issue. Sorry!

[justinpakzad]

We had the same issue. I think it was fixed in #65222.

[venkatamandavilli-code]

Thanks for the detailed report.

This looks like an important issue because DAG versioning should ideally reflect meaningful DAG definition changes, not runtime-generated values that change on every run.

The observation that setting logical_date=None stops the version from increasing is useful. It suggests that the default logical_date value in TriggerDagRunOperator may be introducing a dynamic timestamp into the serialized DAG representation, which then causes Airflow to treat each run as a new DAG version.

From an operational perspective, this could create confusion in environments that rely on DAG version history for auditing, troubleshooting, and deployment traceability. If the DAG structure has not changed, the version should probably remain stable.

It may be worth checking whether logical_date should be excluded from the serialized fields used for DAG version comparison, or whether the operator default should avoid evaluating a dynamic timestamp at parse/serialization time.