You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Serialized tasks repeat timedelta fields that match client_defaults #75547
Serialization omits a task field when it matches client_defaults or the schema default, but timedelta fields never match: the operator value (timedelta(seconds=300)) is compared with the serialized one (300.0). So every task carries these fields itself:
The comparisons are in SerializedBaseOperator._matches_client_defaults and the schema-default check in _is_excluded (airflow-core/src/airflow/serialization/serialized_objects.py). generate_client_defaults already compares the serialized value for this case.
Behavior is unaffected, since deserialization merges client_defaults back. Only the serialized Dag is larger than needed.
What you think should happen instead?
No response
Operating System
No response
Deployment
None
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?
Behavior is unaffected, since deserialization merges client_defaults back. Only the serialized Dag is larger than needed.
Trade-off of fixing it: retry_delay is in every task even with default config, so a fix changes the dag_hash of almost every Dag, and each one gets a new Dag version once after upgrading.
Is this worth fixing in a minor release, given that? If so, I'd like to work on it.
Since the user facing behavior is unaffected, we can solve this in 3.5.0. We need to figure our how can we solve the correct semantic that we pointed out in #75387 (comment) before going further.
Activity
Omit timedelta fields matching client_defaults or schema defaults (ap…
jason810496 commentedon Oct 27, 2026
Since the user facing behavior is unaffected, we can solve this in 3.5.0. We need to figure our how can we solve the correct semantic that we pointed out in #75387 (comment) before going further.