@mdangelo6 I think these failing specs are flaky on master as well, they fail in the same way on fresh master for me, can you validate if you get a chance?

Valid 👍 I think using the WorkItemAsEpic class that Gosia added is the correct place, since this is largely concerned with that presented of a work item as a legacy epic, let me know what you think 👍

yeah I think thats a great idea, I included the logic in the WorkItemAsEpic class instead and made some of the naming more specific 👍

@nicolasdular yes that sounds good I moved it into WorkItemAsEpic with the rest of the logic 👍

Nasser Zahrani (364891cc) at 17 Mar 01:06

... and 37 more commits

Nasser Zahrani (67cc79a9) at 16 Mar 21:18

... and 1508 more commits

Nasser Zahrani (46d75312) at 16 Mar 21:15

... and 15 more commits

Nasser Zahrani (d3f9bba8) at 16 Mar 21:10

Nasser Zahrani (6c1ac12e) at 16 Mar 19:12

... and 950 more commits

Nasser Zahrani (a9b1e8ac) at 16 Mar 17:35

@nicolasdular good question, I should have added this to the local testing step but the guard clause in the awardable_work_item_id field already handles this, if you add an award emoji to a non-epic and query for it you won't see it

[
  {
    "id": 302,
    "name": "thumbsup",
    "user": {
      "id": 1,
      "username": "root",
      "public_email": "",
      "name": "Administrator",
      "state": "active",
      "locked": false,
      "avatar_url": "http://127.0.0.1:3000/uploads/-/system/user/avatar/1/avatar.png",
      "web_url": "http://127.0.0.1:3000/root"
    },
    "created_at": "2026-03-16T13:49:56.499Z",
    "updated_at": "2026-03-16T13:49:56.499Z",
    "awardable_id": 729,
    "awardable_type": "Issue",
    "url": null
  }
]

This still raises the question of if a legacy epic entity is better since there will be a few references we migrate (notes, resource state events, award emojis and resource label events

But strong opinion weakly held, these lightweight EE entities are fine and simplistic enough, WDYT? @nicolasdular

https://console.postgres.ai/gitlab/gitlab-production-main/sessions/49727/commands/148108

@bhrai @emmaspark woops, pasting is hard 😓

@emmaspark Thanks for the initial look! I went ahead and found an epic on gitlab-org with 800 epic issues and attached a query plan if you're able to take another peek

@emmaspark yeaaaaah naming is hard, I prefer to keep the method name here so I've gone ahead and updated the comment to specify that you're also bundling in the preloads 👍

@bhrai would you be able to provide maintainer review here?

Verified both partial unique indexes exist on issue_user_mentions and are valid, so both conflict clauses will resolve correctly

Query plans look fine, the note mentions plan shows ~12.7s for a 10k row batch but more than half of that is the node_id FK validation trigger, which scales linearly so the actual sub batch sizes were working with should be fine.

Agreed with the DO NOTHING point you raised as well, seems unnecessary to take action when were migrating away from the epic data anyways, happy to pass this to maintainer 👍

What does this MR do and why?

This MR backfills the issue_user_mentions table with data from the epic_user_mentions table. Right now, creating a new epic happens through the work items framework, causing both tables to be written to. The aim of the backfill is to move historical data into the issue_user_mentions table.

References

• #454433

Screenshots or screen recordings

Not provided

Database Query Plans

Note mentions: https://console.postgres.ai/gitlab/gitlab-production-main/sessions/49745/commands/148122

Description mentions: https://console.postgres.ai/gitlab/gitlab-production-main/sessions/49745/commands/148121

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #454433

nit 100 seems a little conservative, the query plans are healthy at 10k rows so 1/10 of that should be safe

yeah I think DO NOTHING as well, the alternative is update the epic data to match for correctness, but it feels pointless to actively update legacy data we're moving away from, so no issues

Nasser Zahrani (413e4493) at 11 Mar 22:00

... and 1989 more commits