Handling errored changesets

Publishing a changeset can result in an error for different reasons.

Sometimes the problem can be fixed by automatically retrying to publish the changeset, but other errors require the user to take some action.

Errored changesets that are marked as Retrying are being automatically retried:

Changesets that are marked as Failed can be retried manually:

Types of errors

Examples of errors that can be fixed by automatically retrying:

• Connecting to the code host failed
• Code host responds with an error when trying to open a pull request
• Internal network errors
• ...

Examples of errors that requires manual retrying:

• No Batch Changes credentials have been setup for the affected code host
• The configured code host connection needs a different type of credentials (e.g. with SSH keys)
• A pull request for the specified branch already exists in another batch change
• ...

Automatic retrying of errored changesets

When Sourcegraph batch changes marks a changeset as Retrying it's automatically going to retry publishing it for up to 60 times.

No user action is needed.

Manual retrying of errored changesets

Changesets that are marked as Failed won't be retried automatically. That's either because the number of automatic retries has been exhausted, or because retrying won't fix the error without user intervention.

When a changeset failed publishing, the user can click Retry on the error message. No re-applying needed.

Additionally, in order to retry all Failed (or even Retrying) changesets manually, you can re-apply the batch spec.

Option 1: Preview and re-apply the batch spec in the UI by running

src batch preview -f YOUR_BATCH_SPEC.batch.yaml

and clicking on the printed URL to apply the uploaded batch spec.

Option 2: Re-apply directly by running the following:

src batch apply -f YOUR_BATCH_SPEC.batch.yaml

See "Creating a batch change" for more information on these commands.