Comment 1 for bug 662912

Notes...

Here's an example of the librarian's log for an instance of the first one (https://lp-oops.canonical.com/oops/?oopsid=OOPS-1753S156):

2010-10-19 15:37:21+0000 [-] Starting factory <twisted.web.proxy.ProxyClientFactory instance at 0x61b6fc8>
2010-10-19 15:37:21+0000 [ProxyClient,client] 91.189.90.174 - - [19/Oct/2010:15:37:20 +0000] "GET /57500648/e47a938c-d605-11df-88ae-001e0bc3957e.txt HTTP/1.0" 404 146 "-" "Python-urllib/2.6"
2010-10-19 15:37:21+0000 [ProxyClient,client] Stopping factory <twisted.web.proxy.ProxyClientFactory instance at 0x61b6fc8>

The second one:

2010-10-19 15:39:46+0000 [-] Starting factory <twisted.web.proxy.ProxyClientFactory instance at 0x5efc8c0>
2010-10-19 15:39:47+0000 [ProxyClient,client] 91.189.90.174 - - [19/Oct/2010:15:39:46 +0000] "GET /42395443/tdGJABsFQRvCCFlFQFUZlZSJOd9.txt HTTP/1.0" 404 146 "-" "Python-urllib/2.6"
2010-10-19 15:39:47+0000 [ProxyClient,client] Stopping factory <twisted.web.proxy.ProxyClientFactory instance at 0x5efc8c0>

I'm not sure yet what that buys me, other than being potentially interesting that it doesn't report an error. I don't understand why the ProxyClientFactory is starting and stopping yet.

mbarnett helped me use the second one as verification that the database tables are up to date on staging: the following query did return the appropriate value on staging, identical to production.

SELECT LibraryFileAlias.content, LibraryFileAlias.date_created, LibraryFileAlias.expires, LibraryFileAlias.filename, LibraryFileAlias.hits, LibraryFileAlias.id, LibraryFileAlias.last_accessed, LibraryFileAlias.mimetype, LibraryFileAlias.restricted FROM LibraryFileAlias, LibraryFileContent WHERE LibraryFileAlias.content = LibraryFileContent.id AND LibraryFileAlias.id = 42395443 AND LibraryFileAlias.restricted = True

https://pastebin.canonical.com/38822/

That query mirrors the search done in lib/canonical/librarian/db.py, in Library.getAlias, after the token code that should not be pertinent in this case.

        alias = LibraryFileAlias.selectOne(AND(
            LibraryFileAlias.q.id==aliasid,
            LibraryFileAlias.q.contentID==LibraryFileContent.q.id,
            LibraryFileAlias.q.restricted==restricted,
            ))
        if alias is None:
            raise LookupError("No file alias with LibraryFileContent")
        return alias

So, that LookupError shouldn't be the one triggering a 404.

The only other reasonable possibility for a 404 seem to be if the hostname does not match up (see canonical/librarian/web.py in LibraryFileAliasResource .getChild in the block that includes "if '.restricted.' in hostname:"). I think we'll need to add some logging to investigate that, so I'll do that next.

The other possibilities in web.py are if the alias is not an int (it is, 42395443) or if the dbname is not the same as what came in the request (it is, tdGJABsFQRvCCFlFQFUZlZSJOd9.txt).

So, I'm hoping it is that hostname thing.