Bitbucket API merge returns 202 even when async param is false

[adrian_hernandez_odigeo]

I have a job in Jenkins that merges a BitBucket branch using the Bitbucket API v2.

I am receiving always a 202 status code and I am not sure when this started to happen, because some time ago it wasn't like that, I was receiving 200.

Based on the documentation, there is an optional parameter async that makes the merge in the background, returning 202 with a URL in the header to poll for the status. The documentation specifies that the parameter is false by default and I am not sending it, so I don't see why it's returning 202. But even if I send the parameter with false, I keep receiving always the 202 status code.

Is the documentation outdated and now it's always merging in background? Is that a bug that I should report somewhere?

[Theodora Boudale]

Hi Adrian,

Our engineering teams are in the process of migrating many of our core services onto new infrastructure. The move has contributed to recent performance issues that you can read about here:

• https://bitbucket.org/blog/encountering-some-turbulence-on-bitbuckets-journey-to-a-new-platform

All Bitbucket Cloud merges are performed asynchronously, be it via the UI or via the API. When using the API, if the merge task completes within a timeout threshold, you will receive 200 response code with the response in JSON format. If the merge takes longer than the timeout threshold, you will receive 202 response code with a polling link in the response header. This is a task-status API endpoint you can poll for the result of the merge task. Please be aware that due to higher latencies post our infrastructure migration it may take longer to receive a success result. If you used our merge API before, you would have received a 500 response after the threshold timeout so your workflows might need to be updated to account for the new 202 response code.

This is the behavior by default, where async query param is set to False, which allows you to receive 200 response within the timeout, before returning 202. You can set this param to True and receive 202 straight away, which allows you to start polling the link on your end right away.

We are aware that this behavior is not well explained in our API docs here:

• https://developer.atlassian.com/bitbucket/api/2/reference/resource/repositories/%7Bworkspace%7D/%7Brepo_slug%7D/pullrequests/%7Bpull_request_id%7D/merge

Our Dev team has an internal ticket in place to get this document properly updated in the next 2 weeks.

We appreciate your patience during these times.

Kind regards,
Theodora