@tskorupa-gl

Sorry I will be on PTO next week and I will not be able to complete this review.

1 year, 6 months, 2 weeks, 2 days, 16 hours, 36 minutes, and 12 seconds

The current estimation seems still a bit off, can we check with the groupvulnerability-management to see if this is the best way to achieve this migration.

👋 @minac can you help us here please?

@l.rosa

I changed the direction of this MR and implemented the stale scope to make sure running jobs get picked up and the worker finalized.

I think this will better solve our current problem, let me know what you think 🏌️

Quick thing: Do we want to re-enable the old cron job? I'm afraid we don't have any active process deleting these emails.

Yes I was considering bringing it back as well, opened up BBO - Disable UnconfirmedSecondaryEmailsDeletio... (!225654 - merged).

@l.rosa

Do we want to check this separately? In this condition, I think we'll finalize the worker even if we still have pending jobs:

Yes, I think we need the stale scope to make sure we don't finalize the worker in this situation.

Max Orefice (5bee4ff7) at 13 Mar 14:45

👋 @l.rosa can you review this MR please?

What does this MR do and why?

This MR reverts !225654.

It enables back the old worker UnconfirmedSecondaryEmailsDeletionCronWorker to make sure we continue to delete secondary emails.

Max Orefice (5723497d) at 13 Mar 14:19

Why is this change being made?

This adds the implementation ADR to the Artifact Registry blueprint. See gitlab-org/gitlab#590282.

Related Issue: gitlab-org/gitlab#590365

Action items:

• ensure that all tables have the namespace_id.
• have some words on the partitioning strategy for the blob storage central tables.

Author and Reviewer Checklist

Please verify the check list and ensure to tick them off before the MR is merged.

• Provided a concise title for this Merge Request (MR)
• Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
  • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added, and the content is SAFE
• Assign reviewers for this MR to the correct
  • The when to get approval handbook section explains when DRI approval is required
  • The who can approve handbook section explains how to identify the DRI
  • If the MR does not require DRI approval, consider asking someone on your team, such as your manager.
  • The approver may merge the MR. If they approve but don't merge, you can merge.
• For transparency, share this MR with the audience that will be impacted.
  • Team: For changes that affect your direct team, share in your group Slack channel
  • Department: If the update affects your department, share the MR in your department Slack channel
  • Division: If the update affects your division, share the MR in your division Slack channel
  • Company: If the update affects all (or the majority of) GitLab team members, post an update in #whats-happening-at-gitlab linking to this MR
    • For high-priority company-wide announcements work with the internal communications team to post the update in #company-fyi and align on a plan to circulate in additional channels like the "While You Were Iterating" Newsletter

---

question (not-blocking): Curious how the orphan check discovery/clean up will be done.

I'm fine with both approaches, text with limit is simpler and fine for an ADR, lookup table can come at implementation time.

@dmeshcharakou

Thanks great work, the Database is in good shape, approved 👍

question: Is the limit big enough here?

Same question for other url fields.

🎉 achievements:

• We identified a bug preventing to finalize the worker when max_cursor is reached, BBO - Handle stale running jobs (gitlab!226845 - merged)
• We discovered a stale job preventing the worker to be finalized, BBO - Handle stale running jobs (gitlab#593371)

blockers:

• The team is still at low capacity.

/cc @l.rosa @praba.m7n

🏓 @stomlinson

@tskorupa-gl

I've actually added back reverse_lock_order: true with :projects as the target.

It think this can still avoid deadlocks with concurrent queries.

Max Orefice (a84b21d7) at 13 Mar 09:29

@contributors.gitlab.com

Sorry I'm at capacity and will not be able to review this MR today.

---

👋 @kgreif can you review this MR please?

@krasio

Not sure how likely is to have a single records on issue_metrics though.

This is a bigint conversion which uses a different codepath, so they shouldn't be impacted isn't it?

It calls ensure_backfill_conversion_of_integer_to_bigint_is_finished which goes through BigintConverter.

This also means that the original migration 20260302103000 will also be executed later, though it should be a no-op at this time as the affected background migration should be executed at this point.

Yes, the original migration 20260302103000 will run later on upgrade to %18.10 but will be a no-op since the affected BBMs would have already been re-executed by then.

@krasio

Not if the finalized migration was already executed (for example in previous upgrades to 18.9.X).

Oh I thought the scheduler will pick them up regardless of their status (0 or 1).

Updated the status in !227004 (9df3f5d0)

It's the same for the original migration too.

Do we also need to change it to active Retry BBMs affected by single-record bug (!225461 - merged)?