Open Bug 1493970 Opened 7 years ago Updated 7 years ago

CrashVerify should surface errors

Categories

(Socorro :: Webapp, task, P3)

Tracking

(Not tracked)

People

(Reporter: willkg, Unassigned)

Details

The CrashVerify API endpoint is nice, except that it doesn't surface errors. So any kind of error will result in the CrashVerify API saying that the crash report isn't in that destination. The CrashVerify API endpoint is public, so anyone can use it. I don't think we want to surface errors in the output of the endpoint. However, we should send any errors to sentry. For example, right now it's getting back an HTTP 405 for the telemetry bucket. That would be nice to know without having to comb through webapp logs. This bug covers fixing that.
Another thing we should do is change it from true/false into "yes", "no", and "error". Making this a P2 and taking it. The current situation makes this a mediocre diagnostic tool.
Assignee: nobody → willkg
Status: NEW → ASSIGNED
Priority: -- → P2
For now, I'm going to switch this to "yes", "no", and "error". That's far more informative than true/false. I'm only using this as a diagnostic tool. When that usage changes, we can make it more resilient.
Ugh. Scratch that--I can't do it because everything is showing up as a CrashIDNotFound with no other information in it. The only way to do what we want here is to rewrite the underlying crashstorage code and I don't want to do that. We'd need to rework crashstorage to differentiate between "the thing isn't there" and "I'm configured wrong or don't have access to that thing". The former is a CrashIDNotFound and the latter is a problem with the configuration or infrastructure that we want to know about. I'm going to unassign myself and make this a P3.
Assignee: willkg → nobody
Status: ASSIGNED → NEW
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.