Follow-up from "Add existence checks around todos migration to ensure it is idempotent"
The following discussion from gitlab-ce!20543 should be addressed: - [ ] @nolith started a [discussion](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20543#note_87293635): (+3 comments) > @stanhu I'm not sure about this. > > If we follow what you suggested in https://gitlab.com/gitlab-com/infrastructure/issues/4555#note_87200871 we will be able to deploy immediately, picking this requires waiting for the 12h QA windows for RC7 on staging, and we also have gcp_migration failover test tomorrow. `stanhu` > Right, I think we'll want this regardless of what we do since this migration can fail partway through. `nolith` > yes, good point. > > @yorickpeterse was also concerned about the content of the down method gitlab-com/infrastructure#4555 `stanhu` > Yeah, that is a separate issue indeed. @yorickpeterse said > The rollback procedure is also problematic, as it performs operations that will lock the entire table (e.g. removing the index), and heavy writes (removing all todos with a NULL project ID, without any batching).
issue