lazr.restful

api oops id is not exposed to client programs

Bug #716174 reported by Martin Pool
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
lazr.restful
Triaged
High
Unassigned
wrested
Triaged
High
Unassigned

Bug Description

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.)

See original description
Revision history for this message
Robert Collins (lifeless) wrote :

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.

Changed in launchpad:
status: Triaged → Invalid
Revision history for this message
Martin Pool (mbp) wrote :

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.

Changed in launchpad:
status: Invalid → Triaged
Revision history for this message
Martin Pool (mbp) wrote :

> 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.

Revision history for this message
Robert Collins (lifeless) wrote :

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

Changed in launchpad:
status: Triaged → Invalid
Revision history for this message
Martin Pool (mbp) wrote : Re: [Bug 716174] Re: api error messages should be machine-readable

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.

summary: - api error messages should be machine-readable
+ api oops id should be exposed to client programs
Revision history for this message
Martin Pool (mbp) wrote : Re: api oops id should be exposed to client programs

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

description: updated
Changed in lazr.restful:
importance: Undecided → High
status: New → Triaged
Changed in wrested:
status: New → Triaged
importance: Undecided → High
Robert Collins (lifeless)
no longer affects: launchpad
Robert Collins (lifeless)
summary: - api oops id should be exposed to client programs
+ api oops id is not exposed to client programs
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.