Fix dead config: scheduler.ignore_first_depends_on_past_by_default

[kyungjunleeme]

[scheduler] ignore_first_depends_on_past_by_default became a dead config in Airflow 3: it is still declared in config.yml with default "True", but no code reads it. The Task SDK hardcoded the default:

DEFAULT_IGNORE_FIRST_DEPENDS_ON_PAST: bool = False

so the regression that #22491 fixed in 2.3.0 came back. Adding a new task to an existing DAG whose default_args set depends_on_past=True leaves the new task in no-status forever (PrevDagrunDep: "previous task instance has not run yet") and the DAG run never leaves the running state. A grep for ignore_first_depends_on_past_by_default across main matches only the config.yml declaration — zero readers. (2.10.5 read it at airflow/models/abstractoperator.py.)

Fix

Wire the default back to the config, the same way 2.10.5 did and the way DEFAULT_RETRIES and friends in the same module still do:

DEFAULT_IGNORE_FIRST_DEPENDS_ON_PAST: bool = conf.getboolean(
    "scheduler", "ignore_first_depends_on_past_by_default"
)

The value flows through OPERATOR_DEFAULTS into the serialization client_defaults, so both regular and mapped operators pick up the configured default on the scheduler side. The server-side schema default stays False, so setting the config to False continues to disable the behavior (no client_defaults entry is emitted in that case).

Tests

• task-sdk: default is True, explicit override wins, and the default follows the config (reload guard against the dead-config regression).
• airflow-core PrevDagrunDep: a new task with depends_on_past=True passes its first run using only the config default.
• Updated expectations that pinned the old hardcoded default: test_dag_serialization (operator defaults and the serialized-DAG client_defaults ground truth, which now carries ignore_first_depends_on_past=True) and test_mappedoperator.
• OpenLineage: the task facet now reports ignore_first_depends_on_past=True on Airflow 3.2+. test_task_info_af3 derives the expected value from the operator so it stays correct across core versions (the Compat 3.0.x provider jobs run it against older cores where the default is still False); the AF3 expected_events system fixtures are updated to match.

related: #17585, #22491

---

Was generative AI tooling used to co-author this PR?

• Yes — Claude Code (Opus 4.8)

Generated-by: Claude Code (Opus 4.8) following the guidelines