distributionsourcepackage not created before job

[Curtis Hovey]

OOPS-1670ED2787 reports: AssertionError: DistributionSourcePackage record should have been created earlier in the database for distro=debian, sourcepackagename=pygi. I beleive Ubuntu is the only distro guaranteed to have a row for a published package in DSP.

[Curtis Hovey (sinzui)]

Hi Edwin.

I am unsure if this bug is a registry issue of a bugs issue. This oops could be caused by a trigger or a proc. I need your help triaging this. I have checked in staging and I can see there is a lots of data for debian (13241 rows) so I think debian has lots of data.

/me also sees that there are 20106 rows for Ubuntu.

[Edwin Grubbs (edwin-grubbs)]

Curtis, I raise this oops explicitly in mode/distributionsourcepackage.py to verify whether DistributionSourcePackage can become a storm class safely. Apparently, some code is trying to set a database backed attribute on DistributionSourcePackage, so it goes ahead and creates the DistributionSourcePackageInDatabase object right then. I assume that I am just missing an argument to ErrorReportingUtility.raising() that explains why there is no stack trace for the oops.

[William Grant (wgrant)]

Intriguing timing. I came upon and fixed an issue yesterday in a branch of mine -- gina-created source publications (eg. all of Debian) skipped DSP creation because of badly factored code. Most Ubuntu publications should have had the DSP created at upload time. Could that be related?

[Curtis Hovey (sinzui)]

I do not think gina was involved. There is only one instance of this kind of error this week. I expect gina would make more than one. There is no request, so I think this oops was cause by something internal to the application (not a trigger).

I think the job that caches bug heat or something to do with a bugwatch caused this. I see this relates to changes to bug 604121. I can see debian being selected from spph, there is an insert into bugtask. Looking at the bug, I see bugwatch updater set the debian task to fix released \o/.

[Curtis Hovey (sinzui)]

The Registry team will either remove the code that raises this oops or rethink why it was raised. We want DB storage for operations that report on DSPs such as +needs-packaging. The callsites that are accessing these attrs such as bugwatches are not erroring, nor working with bad data.

[Curtis Hovey (sinzui)]

I can see that most, maybe all, lpnet versions of the oops are for distros other than Ubuntu--this is not an error. Launchpad do not need db backing for these because we know the SPNs can be bogus and there never will be publishing history. BugWatch is the most common reason for this

I can see that most of the edge version of the oops are for Ubuntu. In the gio-sharp example, the first ever bug was reported on the package. it was linked to a project two weeks ago by Jelmer. Bug 629899 was reported for the DSP on 2010-09-03, and that caused a call to DSP.recalculateBugHeatCache(). This is the correct operation. No error for the user and the moment new data was provided launchpad created the db instance. We might think that the DB instance could have been created earlier such as for translatable messages, but gio-sharp has no translatable messages.

[Launchpad QA Bot (lpqabot)]

Fixed in stable r11551 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/11551>.