Azure Devops Status check configuration with reset status breaks analysis

Must-share information (formatted with Markdown):

  • SonarQube Version 9.9 (build 65466)

Hey there,

i am trying to configure a status check in Azure Devops for a SonarQube analysis and i got this error:

Pull Request decoration failed: Unable to contact Azure DevOps Server: Pull request status rejected by status policy. Policy configuration requires status to be posted on iteration

The status on the pull requests stays in the waiting state.

I figured out, that this error only occurs if the status policy is configured with Reset conditions - Reset status whenever there are new changes. If it is configured without this setting, than everything works fine.

What can i do, to get this working with the Reset status toogle?


Welcome to the community!

Where (on which side) did you see this message?

It’s not clear to me how you’re trying to configure this. Are you using a commercial edition of SonarQube?


Hey :wave:

I am using sonar enterprise and I am seeing this error message in the background tasks of the project in sonarqube. The waiting state is shown for the status check in azure devops.

1 Like


The docs make some mentions of branch policies. It looks like this is something you need to configure on the Azure side.


Yes that is correct and there is a setting for „reset status if new changes“ in azure devops but when I activate this flag I get this error in sonarqube.

Hi Ann,

this is the dialogue, i am talking about Azure Devops - Configure Branch Policy

Thanks for looking into it


Backing up…

Why do you need the “reset status” toggle?


The documentation says this

Reset conditions is used to determine when a posted status is no longer valid. If the status posted is specific to the latest code (i.e. a build), check Reset status whenever there are new changes to reset the status when the source branch changes.

as far as i understand this means, that the status check will be reset after new code has been pushed. Am i understand this not correctly?

I want a state where the pull request gets reevaluated if the code changes, e.g. if the first run returns 20% code coverage and than the coverage is improved i want it to succeed if the quality gate has been reached


That’s managed in your CI - a new push should trigger a new build/analysis - and the SonarCloud side. I don’t think you need these policies.