The fork repo naming convention fix made to address https://github.com/sourcegraph/sourcegraph/issues/44456 is not backwards compatible, so customers who use forks with Batch Changes and had open changesets at the time of upgrading to 4.2 or later may encounter issues managing their changesets post upgrade.

This issue was first reported by https://github.com/sourcegraph/accounts/issues/565 immediately following an upgrade with regards to creating a bulk comment on a changeset on a fork. It has since been verified on Bitbucket Server v7.21.7. It affects other operations (close, merge, publish, retry) performed on changesets, as well. The timeline of events that occurs to yield the problem is roughly the following:

1. SG instance has forks enabled for Batch Changes
2. Batch Changes (4.1) goes to publish a changeset on a fork of the repo original-org/repo with a user's PAT
3. Batch Changes (4.1) doesn't find a fork of that repo in the user's namespace, so it creates one under the original (default) fork naming convention: user/repo
4. Changeset is published to user/repo as expected
5. SG instance is upgraded to 4.2
6. User tries to create a bulk comment on their changesets
7. Batch Changes (4.2) goes to load the changeset source and look up the fork repo (the fork is not necessarily indexed by Sourcegraph, so Batch Changes doesn't have a direct link from it to the changeset in the DB)
8. Batch Changes (4.2) doesn't find a fork of that repo in the user's namespace under the new fork naming convention (user/original-org-repo), so it mistakenly tries to create a new one instead
9. Only 1 fork of a repo is allowed per namespace, so the Bitbucket Server API bails out with a somewhat misleading error message:

   loading remote repo: getting namespace fork for external fork namespace: creating fork in "~COURIER-NEW": Bitbucket API HTTP error: code=401 url="https://bitbucket.sgdev.org/rest/api/1.0/projects/BAT/repos/tidb" body="{\"errors\":[{\"context\":null,\"message\":\"You are not permitted to access this resource\",\"exceptionName\":\"com.atlassian.bitbucket.AuthorisationException\"}]}"

To more easily repro this locally, one can do the following:

1. Enable forks
2. Revert the changes from https://github.com/sourcegraph/sourcegraph/pull/43681
3. Create a batch change and publish a changeset to a repo for which a fork does not already exist in your user namespace
4. Restore the changes from https://github.com/sourcegraph/sourcegraph/pull/43681
5. Try to create a bulk comment on the changeset

Bitbucket Cloud is not affected, funny enough. The timeline is the same for Bitbucket Cloud, except that on step 9, the Bitbucket Cloud endpoint for creating a fork is smart enough to just give you the existing fork object back if a fork already exists in that namespace. The end result is that it behaves identically to if Batch Changes had just found the proper fork in the first place.

GitHub and GitLab have not been tested and may be impacted by the same or similar behavior.

I also didn't test this, but it's likely changesets on forks also breaks down on Bitbucket Server if the user has a pre-existing fork of a target repo under a different name, such as the default fork name.

Annoying as it is, I think the only workaround is for customers to close any changesets on repos from <4.2, delete those fork repos, then re-run the batch spec and re-publish them to the newly created forks.