Date strings in DAG params

[hskev]

Hi,

Just updated to the latest Airflow from the last 2.x release.
Now getting quite a lot of DAGs coming up with warnings that I'm looking to resolve.

The warning is:

This Dag uses runtime-variable values in Dag construction.
It causes the Dag version to increase as values change on every Dag parse.

I understand the cause, but I'm looking for a way to keep the functionality working the same.

Params have an output_version param that defaults to the current date in YYMMDD format, but also allows for user modification to any string (including alpha characters).

Right now, I'm using the current_date.format('YYMMDD') string as a default value.

What would be the solution that solves the warning, but keeps this functionality, without adding another task to decide the version?

I've already tried putting a macro ({{ logical_date.format('YYMMDD') }}) as a default value, but it doesn't 'resolve' on the Run Parameters screen.

Thanks!

[TongyiDai]

There is no way for one value to be both “today at trigger time” and a stable parse-time Param default. Airflow must serialize the Param default to build the trigger form and DAG version; a Jinja expression in the default is therefore displayed as literal text rather than rendered against a future DagRun.

The warning is correctly telling you that current_date changes the serialized DAG on every parse. The stable choices are:

1. Use a fixed/nullable string default and let manual users enter the version:

Param(None, type=["null", "string"], title="Output version")

Then inside the task compute params["output_version"] or logical_date.strftime("%y%m%d").

2. If this value is only consumed by templated operator fields, pass the fallback there, for example:

{{ params.output_version or logical_date.strftime('%y%m%d') }}

3. If you require the trigger form itself to be pre-populated with the wall-clock date at the moment the user opens it, Airflow's static Param schema does not support that. A small task/callback or an external trigger UI/API must supply it.

This keeps DAG construction deterministic and stops version inflation while preserving user overrides. Also prefer logical_date/data-interval semantics to datetime.now() for scheduled runs; “today” and the run's logical date are not necessarily the same.