Comment 11 for bug 499095

So there are two causes for builds in this state:

1. We manually reset certain builds so that the related job.date_started was null, but without updating job.status. This was the case with the original build in the description (1226841).

And, thanks to wgrant's help, we found that other occurrences of this build state all mention "E: There are problems and -y was used without --force-yes" in the buildlog, which is used to match the buildd.SBuildExitCode.GIVENBACK status, and following through on that leads to:

2. Builds that result in a buildd.SBuildExitCode.GIVENBACK also have their date_started set to null with the builds put back directly into NEEDSBUILD (ie. leaving the job.status as RUNNING). It looks as though BUILDERFAIL will cause the same issue. Other states destroy the BuildQueue entry, so that IBuild.retry() is called, which creates a new bq entry with a new job.

AFAICS, rhis has only been triggering issues recently due to the recent change in BuildQueue.markAsBuilding() which does not call job.start() if the job is already in the running state.

The fix is simple, we'll see about the test :)