Reported by customer https://github.com/sourcegraph/accounts/issues/569.

Steps to repro:

1. Have batchChanges.enforceForks setting enabled
2. Configure a personal PAT for GitHub to use with Batch Changes
3. Run the hello world spec targeting repos on GitHub and apply the result
4. Publish at least one changeset to GitHub
5. Go back and modify the spec steps
6. Re-run the spec and apply the result

Expected:

• Changes are pushed to the code host and changeset successfully updates

Actual:

• Changes fail to be pushed and changeset shows error message:

Investigation

When we retrieve the fork for a changeset on GitHub that has already been published, we pass the ExternalForkNamespace, which in this case is the user's GitHub username, through to the API client as org, where it is used to construct the request payload:

payload := struct {
	Org  *string `json:"organization,omitempty"`
	Name string  `json:"name"`
}{Org: org, Name: forkName}

However, based on GitHub's own docs, Org should only refer to an organization name, whereas when we have created the fork in a user namespace, we will be providing a user's username. There appears to be no way to specify a different user namespace in which to create the fork apart from one's own currently authenticated user namespace; you must choose either to look in the user's own namespace or look in an organization's. This also means there is unfortunately no workaround until the issue is resolved.

Proposed resolution

There are two approaches we could take to fix this:

1. Try to detect when the ExternalForkNamespace === the currently authenticated user's username and omit it from the call to client.Fork when it is.
   • This method would fail if the changeset already exists in another user's namespace, i.e. if the PAT recently changed, since we would have no way of differentiating a org ExternalForkNamespace vs. another user's ExternalForkNamespace
2. Make an additional API call to try to fetch the fork repo by its ExternalForkNamespace, prior to trying to fork it.
   • This is similar to how it's done on BitBucket Server and BitBucket Cloud since those API's fork methods are "dumber"
   • This is only possible with the changes from https://github.com/sourcegraph/sourcegraph/issues/46096 that also capture ExternalForkName

I will be opting for #2 due to the failure mode of the first option and the fact that https://github.com/sourcegraph/sourcegraph/issues/46096 is already almost completed.