Skip to content

Serialized tasks repeat timedelta fields that match client_defaults #75547

Open

Description

@ChickenBenny

Under which category would you file this issue?

Airflow Core

Apache Airflow version

main

What happened and how to reproduce it?

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:

Config client_defaults.tasks Each task's __var
Defaults none retry_delay: 300.0
default_task_execution_timeout=60, default_task_retry_delay=120 execution_timeout: 60.0, retry_delay: 120.0 retry_delay: 120.0, execution_timeout: 60.0

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.

Are you willing to submit PR?

  • Yes I am willing to submit a PR!

Code of Conduct

Activity

  1. self-assigned this
    on Oct 27, 2026
  2. removed
    needs-triagelabel for new issues that we didn't triage yet
    affected_version:3.4.0rcCan be used for bugs identified during 3.4.0 testing
    on Oct 27, 2026
  3. added this to the Airflow 3.5.0 milestone on Oct 27, 2026
  4. jason810496 commented on Oct 27, 2026

    @jason810496
    Member

    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.

  5. removed their assignment
    on Oct 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind:bugThis is a clearly a bug

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions