## Summary Increase the container registry subrepository limit from 1,000 to 2,000 for project transfers and renames, with the option to raise it to 3,000 later based on observed metrics. ## Background A customer (https://gitlab.com/gitlab-com/request-for-help/-/work_items/4338) is blocked from transferring a project as part of their GitLab Dedicated migration due to the `Too Many Subrepositories` error. Their project shows 942 repositories via the API, but the registry database reports 1,062 repositories because deleted repository records are not cleaned up from the database (tracked in #1750). ### Performance Analysis From [log analysis](https://log.gprd.gitlab.net/app/lens#/edit/aa3bd33c-cca5-4c8c-9b40-50aae5906c35), rename performance across projects shows: | Repositories in project | Rename duration (ms) | |---|---| | 674 | 34 | | 589 | 53 | | 488 | 12 | | 281 | 23 | | 164 | 15 | | 163 | 22 | | 134 | 13 | Extrapolating conservatively (the relationship isn't strictly linear), ~1k+ repositories would complete within ~100ms. Since renames are infrequent, user-initiated operations, increasing the limit poses minimal risk. ## Proposal 1. Increase the limit from 1,000 to 2,000 now 2. Monitor metrics after the change 3. Consider raising to 3,000 later based on observed performance This unblocks the current customer while giving us room to monitor before further increases. ## Checklist - [ ] Implement the limit increase from 1,000 to 2,000 - [ ] Add/update tests for the new limit - [ ] Update documentation to clarify: - [ ] How repositories are counted for the limit (includes deleted/pending-delete repositories still in the database) - [ ] Update the [Troubleshooting "Too Many Subrepositories" article](https://support.gitlab.com/hc/en-us/articles/23654883363100-Troubleshooting-Project-transfer-failed-with-error-Too-Many-Subrepositories) if needed - [ ] Monitor rename performance metrics after deployment