launchpad-dev team mailing list archive

[Bjorn Tillenius <bjorn@xxxxxxxxxxxxx>]

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