Queue priority report processing on first JSON request



9 years ago
6 years ago


(Reporter: davemgarrett, Unassigned)


Firefox Tracking Flags

(Not tracked)




9 years ago
(Bug 412477 comment #5 by Austin King (:ozten))
> Per Bug 484032 you can request 
> http://crash-stats.mozilla.com/dumps/<UUID>.jsonz
> if this is a 404, then you need to request
> http://crash-stats.mozilla.com/report/index/<UUID>
> this will queue up processing the report as a priority job...
> We can add more JSON support. Please file a new bug with details.

I finally got around to rewriting my Crash Report Helper extension to use the newer JSON report instead of just the HTML page for the report. (largely due to the fact that after a recent server update the parser chokes on the new markup) Version 1.2 now fetches what it needs from the JSON:

However, even if I don't need to access the HTML page itself I'm forced to hit it once to request processing before the JSON can be made available. This is easy to do, however it means I'm hitting a page for no reason; many pages if I'm doing all of about:crashes uncached. I would like to not need to do this.

What I'm doing now is hitting the HTML page then looping a check for status 200 on JSON (30s hardcoded interval; 5m default timeout). I would prefer nothing change during the processing period; just have it queue on first hit and show up when done. If you can remove the requirement to hit the HTML page I can remove the half a line doing it and save us all a little bit of waste. :)
Is there any reason that hitting a missing 
shouldn't queue processing for an unprocessed report?  Seems easy enough.
I'd be interested to know the answer to Laura's question too.
(In reply to comment #1)
> Is there any reason that hitting a missing 
> http://crash-stats.mozilla.com/dumps/<UUID>.jsonz
> shouldn't queue processing for an unprocessed report?  Seems easy enough.

I actually think it does now, this was recently moved by Brandon from the web app to the middleware.... my read of http://code.google.com/p/socorro/source/browse/trunk/socorro/services/getCrash.py#47 seems to indicate that it would (that URL gets rewritten to http://socorro-api/crashes/201005/crash/processed/by/uuid/<UUID> and is the same exact call and data that the web app uses for individual crash report pages).

Actually I just tested this on stage (used the collector logs to find a UUID which had been deferred), and it looks like what happens is that a priority processing job is submitted, but the request is abruptly terminated (Firefox shows an error page with "The connection to the server was reset while the page was loading."). However if I continue reloading, it will eventually return the data (which means that a priority job was submitted and is available, eventually).

So I think this is actually working although perhaps we should return a proper status code and message such as "UUID submitted for priority processing, please try again". Not sure what the appropriate HTTP status code would be, maybe "202 Accepted" http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.3 ?
Component: Socorro → General
Product: Webtools → Socorro
Looks like this addon is no longer active - I am pretty sure the new API provides this all just fine https://crash-stats.mozilla.com/api/ (see ProcessedCrash and RawCrash endpoints)
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.