Renovate crashes since 35.155.0 on Azure DevOps - Error: This pull request already targets refs/heads/develop

[chrisvanderpennen]

How are you running Renovate?

Self-hosted Renovate

If you're self-hosting Renovate, tell us what version of Renovate you run.

35.158.0

If you're self-hosting Renovate, select which platform you are using.

Azure DevOps (dev.azure.com)

Was this something which used to work for you, and then stopped?

It used to work, and then stopped

Describe the problem

Starting from v35.155.0, our Renovate runs started failing with the below error. The prior run at v35.154.0 was successful.

Looks like the only relevant change in that release was #23010 which started always setting the target branch in PR update API calls.

I can set up a reproduction if necessary but I think it's pretty clear what the cause is.
I have published a reproduction, links below

Relevant debug logs

Logs

{
  "name": "renovate",
  "level": 50,
  "logContext": "abbeX-OnVnbyEiCXcqK2S",
  "repository": "redacted",
  "branch": "renovate/grpc-monorepo",
  "baseBranch": "develop",
  "err": {
    "statusCode": 400,
    "result": {
      "$id": "1",
      "innerException": null,
      "message": "This pull request already targets refs/heads/develop",
      "typeName": "Microsoft.TeamFoundation.Git.Server.GitArgumentException, Microsoft.TeamFoundation.Git.Server",
      "typeKey": "GitArgumentException",
      "errorCode": 0,
      "eventId": 3000
    },
    "responseHeaders": {
      "cache-control": "no-cache",
      "pragma": "no-cache",
      "content-length": "267",
      "content-type": "application/json; charset=utf-8",
      "expires": "-1",
      "p3p": "CP=\"CAO DSP COR ADMa DEV CONo TELo CUR PSA PSD TAI IVDo OUR SAMi BUS DEM NAV STA UNI COM INT PHY ONL FIN PUR LOC CNT\"",
      "x-tfs-processid": "7db7e707-120e-4c5f-b9cb-0cd2dc580365",
      "strict-transport-security": "max-age=31536000; includeSubDomains",
      "activityid": "7dd006b5-264d-4739-963e-0fc673827274",
      "x-tfs-session": "7dd006b5-264d-4739-963e-0fc673827274",
      "x-vss-e2eid": "7dd006b5-264d-4739-963e-0fc673827274",
      "x-vss-senderdeploymentid": "82bbd8fd-0b52-0619-71dd-a91e6ecc3650",
      "x-vss-userdata": "ecea6ddc-e76a-441e-8080-923965cd64b7:b5a1444b-9c78-4550-a625-dfe370d73fbe",
      "x-frame-options": "SAMEORIGIN",
      "request-context": "appId=cid-v1:81fd8ff6-6d6f-4e9d-9625-8ccf091e088f",
      "access-control-expose-headers": "Request-Context",
      "x-content-type-options": "nosniff",
      "x-cache": "CONFIG_NOCACHE",
      "x-msedge-ref": "Ref A: B88AC711EB804864A6D96A03B6B87A27 Ref B: SYD03EDGE1419 Ref C: 2023-07-01T15:38:48Z",
      "date": "Sat, 01 Jul 2023 15:38:48 GMT",
      "connection": "close"
    },
    "message": "This pull request already targets refs/heads/develop",
    "stack": "Error: This pull request already targets refs/heads/develop\n    at RestClient.<anonymous> (/home/AzDevOps/.npm/_npx/05eeecd92f4e18e0/node_modules/typed-rest-client/RestClient.js:202:31)\n    at Generator.next (<anonymous>)\n    at fulfilled (/home/AzDevOps/.npm/_npx/05eeecd92f4e18e0/node_modules/typed-rest-client/RestClient.js:6:58)\n    at processTicksAndRejections (node:internal/process/task_queues:95:5)"
  },
  "msg": "Failed to ensure PR: Update grpc monorepo"
},

Have you created a minimal reproduction repository?

Repository, build logs

[chrisvanderpennen]

Ahh. Looking at the original reproduction on Azure, automerge was disabled. This looks like an interaction between this change and platform automerge. Let me get a reproduction together.

[chrisvanderpennen]

Nope, the first run where PR's are created works, but a subsequent run with existing PR's is crashing. Reproduction linked.

[viceice]

@RahulGautamSingh it seems we need to revert that part or can you fix that asap?

[RahulGautamSingh]

fixing asap...seems a check needs to be added to confirm that base branch is diff before updating.
I thought it won't matter much since we are updating anyway but did't take into account that the api might not like updating to same ref.

[viceice]

we probably should do it on other platforms too? not sure if any of them has same issue

[RahulGautamSingh]

Yes, applying for all

[moverperfect]

We were experiencing this issue over the last couple of days on Azure DevOps. Can confirm that #23094 and 1700467 have fixed this for us. Thank you for the quick fix