I have an application that encapsulates interaction with the TFS REST API in order to queue a build. The application simply sends the required json to the API and it worked for months until it suddenly started returning 409 - conflict.
System.Net.WebException: The remote server returned an error: (409) Conflict. (https://tfs2015/tfs/spf/SPF/_apis/build/builds?api-version=2.0:{"definition":{"id":190},"parameters":"{}"})
w3.org define the http code 409 as:
The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.
The 409 won't go away either - a simple retry consistently fails. Even the whole "have you tried switching it off an on again" approach of restarting the build servers hasn't helped.
As it turns out the "conflict" in this isn't actually some kind of weird concurrency issue but a state where the build demands couldn't be satisfied.
Basically, the build definition being queued had a demand for "PowerShell = 4". The builds started giving the 409 immediately after the build servers had been updated to PowerShell 5.
In this case the 409 meant that the build demands couldn't be satisfied by any of the build agents in the pool.
Changing the build definition to demand PowerShell instead of a particular version of PowerShell fixed the issue.
(I could of worked this out sooner if my app dumped the entire response to the console so I'll be updating that in the near future).