Question - what woudl be the cases where timing out on migration is "wrong" ? Wouls not that leave the DB in a state that is not expected ? However I think that one is fine to merge as long as we merge #18439 - because then instead of "hanging" migration you'd get hard failure (which is much better).

Is that the idea behind it ?

Question - what woudl be the cases where timing out on migration is "wrong" ? Wouls not that leave the DB in a state that is not expected ? However I think that one is fine to merge as long as we merge #18439 - because then instead of "hanging" migration you'd get hard failure (which is much better).

Is that the idea behind it ?

Actually, there was a timeout in the helm chart until this change: bced2d7 (which is not released yet). So now, it doesn't wait for migration like before.
I added default=60 in the cli_parser but I can remove it if we want. I feel there would be no harm since it's just for checking migrations and would exit once the check is alright

Ah I see. But I hope #18439 could be also merged, that would help A LOT in a meaningful message to the user if the timeout actually happens. Or is timeout equivalent with "error" of the wait-for migration init container andr results with "error" ?

Ah I see. But I hope #18439 could be also merged, that would help A LOT in a meaningful message to the user if the timeout actually happens. Or is timeout equivalent with "error" of the wait-for migration init container andr results with "error" ?

This, #18439 sadly doesn't get hit due to the TimeoutError as I observed. I'm taking a look at fixing it

The PR is likely OK to be merged with just subset of tests for default Python and Database versions without running the full matrix of tests, because it does not modify the core of Airflow. If the committers decide that the full tests matrix is needed, they will add the label 'full tests needed'. Then you should rebase to the latest main or amend the last commit of the PR, and push it with --force-with-lease.