[shivaam]

Unit tests sometimes call clear_db_*() during setup. This can hide database rows leaked by an earlier test instead of fixing the fixture that created them.

This PR adds a small prek check that:

• detects direct clear_db_* calls in pytest fixture setup and xUnit setup methods;
• blocks new affected files;
• temporarily allows the 79 existing affected files;
• removes a file from the allowlist once its cleanup calls are fixed;
• prevents removed files from being added back.

Existing allowlisted files are exempt as a whole. This keeps the first version simple and avoids failures caused by line movement. Future PRs can fix those files incrementally.

When the check fails, it explains that the fixture or test creating the rows must clean them during teardown and links to #71577.

This changes test tooling only. It does not change Airflow runtime behavior.

Related: #71577

Validation:

• 978 prek tests passed
• full-repository checker passed
• current-main baseline simulation passed
• formatting, mypy, hook-registration, and commit checks passed

---

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

• Yes — OpenAI Codex

Generated-by: OpenAI Codex

[jroachgolf84]

@shivaam - after this PR is merged, what would be the next-steps/additional changes needed?

[jroachgolf84]

I assume it would be the list here?

generated/known_clear_db_setup.txt

[shivaam]

Yes, broadly. generated/known_clear_db_setup.txt is the migration list for the patterns this guard detects. It contains one entry per affected file, not per cleanup call.

Follow-up PRs can take small groups from that list, fix cleanup in the fixture or test that owns the rows, and remove the setup-time clear_db_* calls. Once a file has no remaining detected calls, regenerating the list removes it, and the guard prevents it from being added back.

We’re also experimenting separately with a runtime detector and the dag_maker asset cleanup gap. Those may help prioritize later work, but they aren’t part of this PR or committed next steps yet.

[potiuk]

Hello @shivaam - thank you for your contributions to Apache Airflow!

The Airflow community has introduced a limit of 5 open pull requests at a time for contributors without write access to the repository. You currently have 6 open pull requests, so - as a one-time step of introducing the limit - we closed the ones where maintainers have not engaged yet:

• Prevent tasks from writing XComs as other task instances #70969 - Prevent tasks from writing XComs as other task instances
• Prevent new setup-time database pre-cleaning in unit tests #71589 - Prevent new setup-time database pre-cleaning in unit tests

These pull requests stay open because maintainers are already engaged in them - they count towards your limit:

• Handle missed deadline alerts when DagRuns fail #68961 - Handle missed deadline alerts when DagRuns fail
• Speed up Celery task publishing with Redis pipelines #70455 - Speed up Celery task publishing with Redis pipelines
• Batch triggerer unused trigger cleanup deletes #70961 - Batch triggerer unused trigger cleanup deletes
• Add Dag ID filtering to Assets search #70971 - Add Dag ID filtering to Assets search

This is not a judgement of you or of your changes. We never told contributors before that opening many pull requests at once was a problem, so there is nothing to feel bad about - and nothing is lost: your branches, commits and the review history stay where they are.

What we ask you to do is to make your first prioritization decision: choose which of the pull requests above matter most to you, and reopen them (up to 5 open at a time, including the ones still open) with the "Reopen pull request" button or gh pr reopen <PR_NUMBER> --repo apache/airflow. Reopen the ones you are ready to follow through - keep them rebased, respond to review comments and fix failing checks.

While your pull requests are waiting for review, the most valuable thing you can do is help in other ways - reviewing other contributors' pull requests, helping with issues, and taking part in the discussions on the devlist and Slack.

Why we introduced the limit, what it means for you and how to reopen or restore a pull request is explained in https://github.com/apache/airflow/blob/main/contributing-docs/32_open_pull_request_limit.rst.

---

Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting