On Tue, Mar 02, 2010 at 03:05:01PM +0000, James Westby wrote: > 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.
Wouldn't it be possible to calculate the tag only using attributes that a user actually can modify? -- Björn Tillenius | https://launchpad.net/~bjornt _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
