DistroArchSeriesBinaryPackage:+index needs to batch publishing history rows
Bug #2009357 reported by
Guruprasad
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Launchpad itself |
Triaged
|
Low
|
Unassigned | ||
Bug Description
https:/
The OOPS for an instance of this issue is https:/
Related branches
~cjwatson/launchpad:better-oops-traceback-annotations
- Jürgen Gmach: Approve
-
Diff: 225 lines (+94/-37)3 files modifiedlib/lp/services/timeline/requesttimeline.py (+57/-3)
lib/lp/services/webapp/adapter.py (+8/-34)
lib/lp/services/webapp/tests/test_statementtracer.py (+29/-0)
| Changed in launchpad: | |
| status: | New → Triaged |
| importance: | Undecided → Low |
| tags: | added: oops timeout |
Revision history for this message
| Colin Watson (cjwatson) wrote | #1 |
| description: | updated |
| summary: |
- https://launchpad.net/ubuntu/bionic/arm64/grub-efi-arm64-bin times out + DistroArchSeriesBinaryPackage:+index needs to batch publishing history + rows |
To post a comment you must log in.
Now that I can get more detail out of an OOPS generated on a non-production instance, I can see that the basic problem here is that phased updates are resulting in a very large number of rows to display in that table. Phasing used to typically operate in 10% increments, but since April 2021 grub2 has been handled in a "slow" mode where it operates in 1% increments. This means that there are many more publishing history rows: a query on staging shows 680, and by now there are probably a few more than that on production. This is far too many to render without batching.
The fix should be to apply batch navigation to this page. Compare `lib/lp/