api oops id is not exposed to client programs

[Martin Pool]

At the moment if an API call fails with, for example, a 503 or 500
oops, you get back a quite large page of html. It is hard for client programs to do anything with this except dump it to the screen which is ugly. As a result many API failures do not have a visible oops, which makes it harder for the client to know what the problem is, or to give feedback to the Launchpad developers.

Launchpad apparently sends back an X-Lazr-OopsID on some (most?) failed requests. If this was parsed out and put into a structured field then clients could eg show a short message to the user about the failure, or accumulate a list of requests that failed and their corresponding oopses.

(Separately, it might be nice if the response to failed api requests was a json description of the problem, not html, but that's less important. It does not need to be a fine-grained description: just a dict pointing to the oops id, traceback, etc would be enough.)

[Robert Collins (lifeless)]

I'm marking this invalid - let me explain.

We mark exceptions for machine readable status on a case by case basis. The infrastructure for doing it already exists.

If we haven't marked it as machine readable, then by definition its not machine readable yet. This bug is asking AIUI for a systematic 'make all not-marked exceptions machine readable'. I don't think this makes sense: we have a drive-to-zero policy on oopses and timeouts, and any exception that isn't marked as machine readable will show up in the lists of things we're driving to zero.

The result of a developers analysis of that will be to either fix it, or mark it as machine readable because its a logic error on the client causing it.

Either way, we don't need a work item saying we should do this, because we're already doing it.

[Martin Pool (mbp)]

I'm going to reopen it for the sake of discussion.

When a web ui request fails, it includes the OOPS id in a readable form so that users can see it and include it in a bug report. Robert stated he thinks its useful to have users file bugs about OOPSes that cause problems for them.

The web api is asymmetric with this this because the OOPS id is easily lost. Is that useful?

Is there any reason it's positively useful to send HTML requests to machine requests? Why not turn this on across the board.

Every program tries not to have bugs. It's still worth having proper reporting of bugs when they do occur.

[Martin Pool (mbp)]

> any exception that isn't marked as machine readable will show up in the lists of things we're driving to zero.

OK perhaps this is the key thing: it seems like fixing this bug acceptably would mean teaching Launchpad that sending an error in machine-readable form doesn't imply it should be omitted from the OOPS reports.

[Robert Collins (lifeless)]

No, it would require an oracle to convert arbitrary unexamined exceptions into structured data. I don't think this is easy, nor worth doing.

[Martin Pool (mbp)]

Robert says there is an X-Lazr-OopsID in failed api requests, so it is
already there in a reasonable form. At the moment I don't think
lazr.restful makes this available to the client and it probably
should, as should wrested.

This bug could be handled by clients looking for that header and
reporting it if it's present.

I still think it would be cleaner to not send html errors to api
clients. But obviously the clients do need to tolerate getting back
html that might come from an intermediate proxy or whatever.

[Martin Pool (mbp)]

Robert says this should be 'high' in lazr.restful, to speed up feedback from api clients to launchpad developers.