Delay between blob submission and blob availability causes Launchpad to OOPS.

I can confirm this is happening on Ubuntu 8.10 for me too. Not only rhythmbox is affected, but so far every app I have tested. For example, FireFox tries to go to this URL if I repeat this process for Evolution:

https://bugs.launchpad.net/ubuntu/+source/evolution/+filebug/6Wfu7sNmvj9mrbDEtCEX5ftjMo3?

Ouch.

This would be blocking everyone from using these options, for any program. Marking critical.

I can reproduce this using gedit. I can't tell whether this is a problem with launchpad-integration or with Launchpad Bugs, so I'm adding this task and will investigate tomorrow.

Note the last comment of https://bugs.edge.launchpad.net/ubuntu/+source/python-launchpad-bugs/+bug/309307/comments/17 - looks like it's launchpad side, where it hasn't generated the report quickly enough.

As Sarah pointed out, waiting and refreshing makes everything work nicely. The added token at the end is generated by Launchpad and returned to the launchpad-integration package in an X-Launchpad-Blob-Token header (James Westby explained this on IRC).

So it appears that Launchpad is generating a token for the uploaded blob and then pretending that the token doesn't exist, which is positively weird.

This could be fallout from the replicated db setup?

On Mon, Jan 05, 2009 at 12:35:13AM -0000, Michael Hudson wrote:
> This could be fallout from the replicated db setup?
>

That's my suspicion, too. I'll investigate and see if that's the case.
If it is, it should be trivial to fix.

Setting this to invalid for launchpad-integration; the problem is with Launchpad itself.

This was opened and Confirmed against Launchpad itself and apport in bug 310016 which has been marked as a duplicate of this one. I'll re-apply that affects/status here since that seems to be the source of the problem (not apport).

I'm marking the Launchpad task invalid since the bug is specifically in the Launchpad bug tracker, for which there is already a task.

This is almost certainly fallout from database replication. During normal operation, it will take 30-60 seconds for the information about the upload to propagate to the replica database. It is quite likely that when attempting to view this page with a web browser, the replica database is hit and the information doesn't yet exist.

It may be a simple solution to force the use of the master for this particular page. This would be a malone fix.

An alternative is to update the publisher so, if a 404 is generated and the replica database used, the request is retried using the master database (quite similar to the Retry mechanism used to handle database deadlocks and serialization exceptions). This would be an infrastructure fix.

Confirming as an infrastructure issue - I think we can preemptively solve similar issues too.

I'll see if my approach is sane. It would be nice if we only had to fix this class of problems once (codehosting has a similar race condition - push a branch and go to the URL and it isn't there yet).

It makes sense to fix at the infrastructure level.

Marking this Won't Fix for malone since Stuart's solution should take care of the problem across all Launchpad apps.

Stuart, will the fix for this also make the Librarian retry using the slave store, if a LibraryFileAlias can't be found? If not, I suspect that the problem that was original reported will still persist, although instead of a 404, it will oops like OOPS-1104F1950.

Or does the Librarian always use the master store?

The librarian always use the master store.

Request for this to be cherry picked, so I guess this is critical.

I've found that navigating away from the generated Launchpad bug report page & coming back to it causes it to work. I made mention of this happening in a bug report I filed for another package & was directed here. My comments are in bug 311041.

I just tried this again, running "ubuntu-bug gourmet" to generate a new bug report. A Launchpad URL w/gobbledygook was launched & reported: "Lost something? There’s no page with this address in Launchpad. Check that you entered the address correctly." It opened the page for the correct package, however.

I navigated away from that page & used the back button to return to it after a short time & the report then worked. This makes sense to me now in light of what has been said above.

r7556