Pipeline runner hosted build is failing with 500 error in Bitbucket Cloud
Platform Notice: Cloud Only - This article only applies to Atlassian apps on the cloud platform.
Summary
Pipeline builds running on a Self-hosted Runner fail. The following error message shows on a build's page (on Bitbucket's website):
Error
Unable to fetch step. Refer to the Troubleshooting runners document for help resolving the issue. The following error shows in the runner's log:
com.atlassian.pipelines.stargate.client.core.exceptions.StargateInternalServerErrorException: Response Summary: HttpResponseSummary {httpStatusCode=500, httpStatusMessage=Internal Server Error, bodyAsString={"code":500,"message":"There was an error processing your request. It has been logged (ID XXXXXXXXXXXX)."}}
Environment
This article is related to builds running on Bitbucket cloud Self-hosted Runners.
Diagnosis
Verify the Self-hosted Runner log and see the following error:
[2023-08-21 13:51:39,393] Getting step StepId{accountUuid={XXXXXXX-XXXX-XXXX-XXXX-XXXX-XXXXXXXXXX}, repositoryUuid={XXXXXXX-XXXX-XXXX-XXXX-XXXX-XXXXXXXXXX}, pipelineUuid={XXXXXXX-XXXX-XXXX-XXXX-XXXX-XXXXXXXXXX}, stepUuid={XXXXXXX-XXXX-XXXX-XXXX-XXXX-XXXXXXXXXX}.
[2023-08-21 13:51:39,401] Getting oauth token for step.
[2023-08-21 13:51:39,413] Getting environment variables for step.
[2023-08-21 13:51:56,647] An error occurred whilst getting oauth token.
com.atlassian.pipelines.stargate.client.core.exceptions.StargateInternalServerErrorException: Response Summary: HttpResponseSummary{httpStatusCode=500, httpStatusMessage=Internal Server Error, bodyAsString={"code":500,"message":"There was an error processing your request. It has been logged (ID XXXXXXXXXXXX)."}}
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
Suppressed: reactor.core.publisher.FluxOnAssembly$OnAssemblyException:
Error has been observed at the following site(s):
*__checkpoint ⇢ 500 from POST https://api.atlassian.com/ex/bitbucket-pipelines/rest/1.0/accounts/%7BXXXXXXX-XXXX-XXXX-XXXX-XXXX-XXXXXXXXXX%7D/repositories/%7BXXXXXXX-XXXX-XXXX-XXXX-XXXX-XXXXXXXXXX%7D/oauth [DefaultWebClient]
Original Stack Trace:Check if the value of the accountUuid field in the above log's first line matches the UUID of the workspace where the repo with the failed build belongs. You can run the following API call on a terminal locally to get the workspace's UUID:
curl -X GET -u <atlassian_account_email>:<api_token> "https://api.bitbucket.org/2.0/workspaces/<workspace-id>?fields=slug,uuid"In the command above, replace:
<atlassian_account_email> with your Atlassian account email address
<api_token> with an API token for your account. The API token needs to have at least the scope
read:workspace:bitbucket.<workspace-id> with the ID of the workspace where the repo with the failed build belongs. You can find that in the repo URL; if the repo's URL is https://bitbucket.org/some-workspace/some-repo/, then the ID of the workspace is some-workspace.
The output will look like this:
{
"uuid": "{XXXXXXX-XXXX-XXXX-XXXX-XXXX-XXXXXXXXXX}",
"slug": "<workspace>"
}For this specific issue, the accountUuid mentioned in the logs will not match your actual workspace UUID.
Cause
This problem typically arises when a repository with a Self-hosted runner setup is moved to a new workspace. Initially, the Self-hosted runner setup associates itself with the original workspace and repository UUID. However, when the repository is transferred to a new workspace, the account UUID changes, while the repository UUID remains the same. This mismatch is what causes the issue.
Solution
You need to have admin access to the repo to perform the following steps. If you don't, please ask a repo admin to follow these steps.
Open the repository on Bitbucket's website.
Select the Repository's settings from the left sidebar.
Select Runners from the new left sidebar (under the section Pipelines).
Find the affected Runner and delete it by clicking on the three-dotted icon (•••) > Delete.
After successfully removing the affected Runner, create a new runner which should now be attached to the correct workspace.
Start the new runner with the preconfigured command provided when you created it in the previous step.
Was this helpful?