DistributionSourcePackageRelease page still oopsing with NotOneError/LocationError
Bug #580181 reported by
Ursula Junque
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Fix Released
|
High
|
Michael Nelson |
Bug Description
As seen on OOPS-1592B957 and OOPS-1593EC1023:
NotOneError: one() used with more than one result available
Also, OOPS-1600E1649:
LocationError: (None, 'filesize')
We're having high counts of the latter on lpnet everyday, between 600 and 700 oopses.
According to bigjools this is related to bug 536641, Fix Released. Can be reproduced in edge and lpnet.
Related branches
lp:~michael.nelson/launchpad/580181-only-one-ds-cache
Merged
into
lp:launchpad
- Curtis Hovey (community): Approve (release-critical code)
- Canonical Launchpad Engineering: Pending requested
-
Diff: 185 lines (+142/-7)4 files modifiedlib/lp/soyuz/browser/tests/test_sourcepackagerelease.py (+59/-0)
lib/lp/soyuz/model/distroseriesbinarypackage.py (+9/-7)
lib/lp/soyuz/templates/sourcepackagerelease-files.pt (+5/-0)
lib/lp/soyuz/tests/test_distroseriesbinarypackage.py (+69/-0)
Changed in soyuz: | |
status: | New → Triaged |
importance: | Undecided → High |
Changed in soyuz: | |
assignee: | nobody → Michael Nelson (michael.nelson) |
summary: |
- DistributionSourcePackageRelease page still oopsing with NotOneError + DistributionSourcePackageRelease page still oopsing with + NotOneError/LocationError |
description: | updated |
Changed in soyuz: | |
status: | Triaged → In Progress |
Changed in soyuz: | |
status: | Triaged → In Progress |
Changed in soyuz: | |
milestone: | none → 10.05 |
Changed in soyuz: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
It certainly looks like the same issue with a new version of java in Lucid:
https:/ /edge.launchpad .net/ubuntu/ +source/ sun-java6/ 6.20dlj- 1ubuntu3/ +build/ 1704548
But last time this happened because the package was uploaded incorrectly to the partner component of the primary archive, but that is not the case this time:
https:/ /pastebin. canonical. com/32299/
Nonetheless, we do seem to have a corrupt cache again, although I'm not sure in this case where the duplicate record has come from. As outlined on bug 536641, we should: "2. Ensure DistroSeries. updatePackageCa che() doesn't create a new cache item for a distro archive if one already exists in another distro archive," to ensure this situation can't happen again.