WorkItems: Update Rolledup dates when a milestone is deleted
What does this MR do and why?
As part of the epic, we need to ensure that when a Milestone is deleted and it's related to a WorkItem in a hierarchy we update all the parent WorkItems in that hierarchy with rolledup dates to use the most broad start/due dates in its hierarchy.
This is being developed behind the feature flag: work_items_rolledup_dates
Related to: #434835 (closed)
Changelog: added
EE: true
FAQ
- Why not create/use a
Milestone::MilestoneDeleteEvent
?- this was my first approach, but once the milestone is deleted we can tell which WorkItems where associated with that milestone afterwards. For this reason I created the
::WorkItems::BulkUpdatedEvent
, which we can in the future also use on other Bulk Edit features, like we have on the issues/merge request list. - The downside/benefit of using
::WorkItems::BulkUpdatedEvent
is that we have to pass the list affected WorkItems on that event. As mentioned, this is helpful when we cannot fetch this data when handling an event, like when deleting an association.
- this was my first approach, but once the milestone is deleted we can tell which WorkItems where associated with that milestone afterwards. For this reason I created the
- Why are we batching the list of
issues
?- There's more than 300 milestones on
gitlab.com
with more than 1000 associated issues. Currently the milestone deletion is already slow because we iterate over all the issue and associated MRs during the deletion. To reduce then+1
I decided to use batches of 500.
- There's more than 300 milestones on
- In this case, why not batch over the MRs as well?
- This MR is already too complex, I'd prefer to do this on a follow-up.
- What change on the database queries?
- Nothing. I moved some code around and group the iteration over the
milestone.issues
, but just to send smaller batches of ids to theGitlab::EventStore
.
- Nothing. I moved some code around and group the iteration over the
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Screenshots or screen recordings
How to set up and validate locally
- Enable
work_items_rolledup_dates
feature flag - Craate a Milestone with start/due dates
- Create some WorkItem issues on the created milestone
- Create a Epic WorkItem with
inheritable dates
- Add the WorkItem issues as children in the Epic, the
inheritable dates
should now match the milestone start/due date (this runs in the background so you might need to restart sidekiq to trigger this properly on GDK) - Delete the Milestone
- Reload the Epic WorkItem page, the
inheritable dates
must be empty (again, this runs in the background so you might need to restart sidekiq to trigger this properly on GDK)
Edited by Kassio Borges