building build without a bq.builder causing LocationError OOPS

Here's the results of some digging around in case anyone else can make something of it:

https://edge.launchpad.net/~mudlet-makers/+archive/ppa/+builds?build_text=&build_state=building

shows the build to be i386 build of mudlet 1.0.4~ppa5 in ubuntu hardy RELEASE

Useful info from the API:
>>> build.title
u'i386 build of mudlet 1.0.4~ppa5 in ubuntu hardy RELEASE'>>> build.datecreated
datetime.datetime(2009, 12, 3, 6, 25, 20, 207807, tzinfo=TimeZone(0))
>>> build.date_first_dispatched
datetime.datetime(2009, 12, 3, 6, 25, 20, 810387, tzinfo=TimeZone(0))
>>> build.upload_log_url

Checking the log for the first dispatch shows:

2009-12-03 06:25:20+0000 [-] startBuild(http://samarium.ppa:8221/, mudlet, 1.0.4~ppa5, Release)
2009-12-03 06:25:21+0000 [-] samarium (http://samarium.ppa:8221/):
2009-12-03 06:25:21+0000 [-] ***** RESULT *****
2009-12-03 06:25:21+0000 [-] {u'mudlet_1.0.4~ppa5.tar.gz': u'07ae2c05958e304df605824aac74650c5ec253a3', u'mudlet_1.0.4~ppa5.dsc': u'07dba242237b634810795fd27f2bca336953d2fb'}
2009-12-03 06:25:21+0000 [-] {'archive_private': False, 'archive_purpose': 'PPA', 'archives': [u'deb http://ftpmaster.internal/ubuntu hardy main restricted universe multiverse', u'deb http://ftpmaster.internal/ubuntu hardy-security main restricted universe multiverse', u'deb http://ftpmaster.internal/ubuntu hardy-updates main restricted universe multiverse'], 'ogrecomponent': u'main', 'suite': u'hardy', 'arch_indep': True}
2009-12-03 06:25:21+0000 [-] BuilderStatus.BUILDING: 1376913-2851644
2009-12-03 06:25:21+0000 [-] ******************
...
Then one minute later, the same build is re-dispatched to the same builder (with the same build queue id - BUILDERFAIL or GIVENBACK)?:

2009-12-03 06:26:21+0000 [-] startBuild(http://samarium.ppa:8221/, mudlet, 1.0.4~ppa5, Release)
2009-12-03 06:26:21+0000 [-] samarium (http://samarium.ppa:8221/):
2009-12-03 06:26:21+0000 [-] ***** RESULT *****
2009-12-03 06:26:21+0000 [-] {u'mudlet_1.0.4~ppa5.tar.gz': u'07ae2c05958e304df605824aac74650c5ec253a3', u'mudlet_1.0.
4~ppa5.dsc': u'07dba242237b634810795fd27f2bca336953d2fb'}
2009-12-03 06:26:21+0000 [-] {'archive_private': False, 'archive_purpose': 'PPA', 'archives': [u'deb http://ftpmaster
.internal/ubuntu hardy main restricted universe multiverse', u'deb http://ftpmaster.internal/ubuntu hardy-security main restricte
d universe multiverse', u'deb http://ftpmaster.internal/ubuntu hardy-updates main restricted universe multiverse'], 'ogrecomponen
t': u'main', 'suite': u'hardy', 'arch_indep': True}
2009-12-03 06:26:21+0000 [-] BuilderStatus.BUILDING: 1376913-2851644
2009-12-03 06:26:21+0000 [-] ******************

After which it is continually redispatched (sometimes with the same bq twice, but normally with a new bq item) until 2009-12-21 18:20:11+0000
http://pastebin.ubuntu.com/352210/

(the build logs for these should be in the librarian right?)

I've just checked the IRC logs, and it looks likely that the above last dispatch on 2009-12-21 18:20:11 was the cause of a complete build farm failure (bug 499421), as there was some SQL run at that point:

https://irclogs.canonical.com/2009/12/21/%23launchpad-code.html#t19:35 (sorry for the non-open link)

which did:

{{{
update job set date_started = null
FROM
    build, buildqueue bq, buildpackagejob bpj, archive
WHERE
    bq.job = bpj.job AND
    bpj.build = build.id AND
    build.archive = archive.id AND
    bq.builder is null AND
    job.id = bpj.job AND
    job.date_started is not null;
}}}

as setting the date_started back to null allowed the build farm to continue in a healthy state. But it does not leave the build in a healthy state. I assume (it would have been good to have had the build id) it is this build that was the culprit, and it had it's date_started set back to null, but the buildstate was still BUILDING - hence this oops.

Julian, as mentioned in our call, I think we should just set the buildstate back to NEEDSBUILD, but I want to do this when we'll be around (not flying) just in case there is something specific about this build which caused bug 499421 in the first place.

So, not a bug, it was caused by some bad SQL trying to fix things.