Launchpad can't always detect when a Trac isn't using the LP plugin

[Graham Binns]

Now that we can disable bugtrackers I was looking at the following items in the OOPS report:

 112 ResponseError: <xmlrpclib.ResponseError instance at INSTANCE-ID>
    Other: 112 Robots: 0 Local: 0
      28 http://xquartz.macosforge.org/trac/ (Unknown)
        OOPS-1190CCW1018, OOPS-1190CCW1047, OOPS-1190CCW1089, OOPS-1190CCW1179, OOPS-1190CCW1207
      28 http://trac.macports.org/ (Unknown)
        OOPS-1190CCW1016, OOPS-1190CCW1045, OOPS-1190CCW1087, OOPS-1190CCW1177, OOPS-1190CCW1205
      28 http://trac.macosforge.org/projects/macports/ (Unknown)
        OOPS-1190CCW100, OOPS-1190CCW1004, OOPS-1190CCW1034, OOPS-1190CCW1060, OOPS-1190CCW1137

Doing some investigation it looks like we're trying to use the TracLPPlugin ExternalBugTracker to handle these when we shouldn't - they don't have the plugin installed. Testing locally showed me why this was happening: the check for the plugin being installed involves going to $base_url/launchpad_auth/check, which should make an auth check against Launchpad. However, in these Tracs it returns a "Not found" error (as you'd expect). The problem is that these Tracs use a 200 status code instead of a 404 for these pages, so our code, which expects an HTTPError if the check fails, doesn't pick up the failure.

We need to update Trac.getExternalBugTrackerToUse() to make it more robust in the face of bug trackers that don't present the information we expect in HTTP headers. One way to do this would be to attempt to make an XML-RPC call like launchpad.time_snapshot() and see what come back.

[Graham Binns (gmb)]

Changing the importance to Low: it seems that the three bug trackers mentioned here have started returning 404s where they should, rather than 200s. Since these were the only Tracs causing the problem I think it's safe to lower the priority of this; we can bump it back up if it happens again.