@srajadas This hasn't really been refined yet - take a look and see what we can do here from the application side?

The operational problem is very similar to the work in https://gitlab.com/groups/gitlab-org/-/work_items/20903+; broadly speaking we have workers running for too long and holding onto scarce resource connections for too long. The work in that epic is more on the infra-ish side, but hopefully here we find some regular old worker improvements we can make.

Thanks for the heads up @thiagocsf - is there any kind of backlog associated with this? Any recent work? I'm not even sure which labels I would use to start looking at this

cc @rutshah

@mfanGitLab Unassigning you from this, as the performance work is largely wrapping up for now and there's nothing you should be actively thinking about

Thanks for picking this up @hfyngvason! I promoted it to an epic and broke out the steps to removal into child issues. The breakdown and scheduling here is a rough prediction, so please do feel free to rewrite, add, remove, rearrange, etc. as necessary.

@disastor Heads up that we're starting on this now, with the intent to sneak a feature flag into %18.10 to support the fetch behavior change in CI. To be clear, this won't stop the creation or deletion of PersistentRef yet, that's later in the process.

@hfyngvason Scheduling this for %18.11, but feel free to pull it up into %18.10 if we have time. "Delivery" of this one is less merge-request centric (unelss there's Gitaly logging work needed?) so I'm not sure how much the code cutoff will matter.