kaxil opened a new pull request, #73242:
URL: https://github.com/apache/airflow/pull/73242

   Two things this page promises about `db clean` are not what the command 
does, and both are the kind an operator acts on.
   
   **The DAG filters do not reach every table.** `--dag-ids` and 
`--exclude-dag-ids` are applied only where a table's cleanup config declares a 
DAG column 
([`db_cleanup.py#L514`](https://github.com/apache/airflow/blob/4c3ec9cbae/airflow-core/src/airflow/utils/db_cleanup.py#L514)).
 Eight of the 21 configured tables declare none and are cleaned whatever you 
pass, so `--exclude-dag-ids critical_dag` reads as "leave that DAG's data 
alone" while `trigger`, `callback`, `import_error` and five others are purged 
in full. The page said the options "allow you to target or avoid cleanup for 
particular DAGs", unqualified.
   
   **`--tables` is where cleanup starts, not what it is limited to.** Each 
table's configured dependents are cleaned first so their rows are archived too, 
so `--tables trigger` also cleans `task_instance`, `task_instance_history` and 
`xcom`, and `--tables dag` cleans eight tables. The page said only that you 
"can optionally provide a list of tables to perform deletes on".
   
   **The fix points at `--dry-run` rather than listing the unscoped tables**, 
which would go stale as tables are added. `--dry-run` already prints a 
`dag_id_column` per table, and `None` there is exactly the unscoped case, so 
the operator reads the answer off the command instead of off a list in the docs.
   
   The new note also stops short of promising that `--tables` makes archival 
complete. That dependents list is [maintained by hand rather than derived from 
the 
schema](https://github.com/apache/airflow/blob/4c3ec9cbae/airflow-core/src/airflow/utils/db_cleanup.py#L115-L118),
 so it does not cover every foreign key: `task_reschedule.ti_id` and 
`task_instance_note.ti_id` both cascade from `task_instance` without being 
among its dependents, and rows lost that way are neither counted in the dry run 
nor archived. The note links this page's existing "Beware cascading deletes" 
section rather than implying the problem is handled.
   
   Related to #73173, which fixes three tables that name a `dag_id` column they 
no longer have. The counts above are measured on `main` and that PR does not 
change them.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to