launchpad-dev team mailing list archive

[James Westby <jw+debian@xxxxxxxxxxxxxxx>]

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