Add a data migration to fix some missing timestamps in the members table (again)
What does this MR do?
Repeats an earlier migration to fix historic bad data in the members table (missing created_at and updated_at fields)
Are there points in the code the reviewer needs to double check?
I'm expecting the WHERE clauses to be fast enough, and to return few enough rows, that the migration doesn't need to use batches, but I'm not too familiar with the size of these tables in the wild, so perhaps that's a poor assumption.
Why was this MR needed?
8.10 introduced a dependency on the members.created_at field in the project and namespace member view. If bad data is present, viewing the list of members now results in an NoMethodError and a 500 response from GitLab. Although the previous migration should have fixed all bad rows, we have evidence that it didn't in at least one case, despite the migration claiming to have run in the past.
What are the relevant issue numbers?
Screenshots (if relevant)
Does this MR meet the acceptance criteria?
- CHANGELOG entry added
- Documentation created/updated
- API support added
- Tests
- Added for this feature/bug
- All builds are passing
- Conform by the style guides
-
Branch has no merge conflicts with
master(if you do - rebase it please) - Squashed related commits together
Closes #20568 (closed)