Hi, With the addition of bug heat there's a danger of a little trap being inadvertently set for those using the API.
If bug_heat is exported as an attribute over the API then it goes in to the calculation of the etag for a bug. That means that bug_heat, like status, importance, etc. can't change between GETting the bug over the API and PATCHing new values to it. However, as bug_heat is decayed using cron it will race with all modifications done over the API, meaning that you will occaisionally get 412 errors from your scripts. There would be a couple of ways of fixing this, such as exporting bug_heat as a method not as an attribute. We already have something like this with, at least, code, where you race with the scanner when pushing up a branch and then modifying an attribute of the branch over the API. You could argue that script authors should deal with 412 errors, as they can happen with concurrent user edits and the like. While that is true, I'm not sure we need to be making it more likely to happen, and racing with automated tasks is less or a reason to conflict anyway. Plus, the facilities for handling conflicts in the API are lacking from where they should be if all API users should be dealing with them. Thanks, James _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
