← Back to team overview

launchpad-dev team mailing list archive

Re: Bug heat and the API

 

Hi, James.

On Tue, Mar 2, 2010 at 9:05 AM, James Westby <jw+debian@xxxxxxxxxxxxxxx> 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.

IBug.heat is already exported.

>
> 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.

I'm open to avoiding 412 errors, certainly!  I don't know that I like
the idea of converting heat to a method.  Seems like a hackish thing
to do, simply because getting a 412 is a pain.  We're only going to be
hitting this more and more as we continue to expose attributes in the
API.  I think we would be better to solve the root problem.

>
> 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.
>

I agree we should have facilities for dealing with the 412 error
better in launchpadlib.

I also think it would be nice to be able to mark an attribute as
ignorable for the sake of calculating the etag when we decorate
attributes for exporting.  If status on a bug changes, that could
matter to a script.  If heat changes, not so much.  Heat can't be set
by an external script anyway.

I wonder if read_only does this or could be made to do this?  I asked
Leonard on IRC and he wasn't sure.  He's also very busy at the moment
to dig further into the question.  This seems a nice solution.  But it
doesn't solve it for attributes that can be set.

Maybe we could provide hooks in launchpadlib for a script to indicate
this, i.e. generate me a 412 if bug status changes because I'm working
with that, otherwise let me do my work in peace.

I think it's worth fixing these issues, or others like them, rather
than trying to do hacks to prevent something affecting the etag
calculation.  But I do realize these issues fall to Leonard often, so
I don't mean to shirk my responsibilities either. :-)

Cheers,
deryck



-- 
Deryck Hodge
https://launchpad.net/~deryck
http://www.devurandom.org/



Follow ups

References