Nice fix — moving _get_info_list ahead of the Backfill insert and swapping the early commit() for flush() in _create_backfill collapses creation into a single transaction, so _mark_backfills_complete() can no longer catch a committed Backfill with zero DagRuns. That retires the 2-minute heuristic from #62561 instead of just tuning it, and the new test genuinely fails on the old path.

One thing before merge, and it's the exact concern #64534 raised: the AlreadyRunningBackfill guard used to lean on that early commit to block concurrent duplicates. With flush(), the new row stays invisible to other sessions until the whole block commits, so the num_active count in _create_backfill — a plain SELECT with no with_row_locks/FOR UPDATE, and no unique constraint on Backfill.dag_id — now has a wider window where two concurrent creates for the same dag both pass it. Could you add a lock around that check (or a partial unique index on dag_id WHERE completed_at IS NULL), plus a test asserting only one of two same-dag creates wins?

Also a heads-up: it's showing CONFLICTING with main, so it'll need one more rebase.