Skip to content

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.
  • 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 the n+1 I decided to use batches of 500.
  • 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 the Gitlab::EventStore.

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

delete-milestone

How to set up and validate locally

  1. Enable work_items_rolledup_dates feature flag
  2. Craate a Milestone with start/due dates
  3. Create some WorkItem issues on the created milestone
  4. Create a Epic WorkItem with inheritable dates
  5. 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)
  6. Delete the Milestone
  7. 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

Merge request reports