456402 - Improve user experience for pending reports

Status: RESOLVED FIXED

(Socorro :: General, task, P1)

Description

[Michael Morgan [:morgamic]]

If a report is not found or we haven't gotten a queued report yet, the pending page should notify the person requesting that report that there is a problem instead of indefinitely spinning.

We need to figure out how to make communication between the reporter and monitor bidirectional so real-time status can be displayed on the pending page and error conditions can be covered.  Lars -- do you have any ideas or suggestions on how to do this?

My thoughts:
* set a timeout limit (2 min?  5 min?) for how long before the pending page whines
* set up error conditions for the priorityJobs scan so it can update the priorityJobs table with an error code/report that the pending page can slurp up

Comment 1

[K Lars Lohn [:lars] [:klohn]]

It should work like this (in Pythonic pseudo code)

if uuid not in reports table:
  submit uuid to priority jobs table
  for every 30 seconds in ten minutes:
    if uuid in jobs table:
      display queued datetime
    if uuid in reports table and success is not NULL:
      display full report
      quit
  if full report wasn't displayed within the allotted time:
     display message disparaging the parentage of the developers, sys admins
else:
  display full report
 


display full report actually means:
  if success is True:
    display all the information about frames, dumps, etc.
  else:
    display the contents of the message column
   #note: message column name to change in the new schema...

Comment 2

[K Lars Lohn [:lars] [:klohn]]

BTW, I've noticed that the refresh on the status pending page is currently failing in staging.  A requested priority job will refresh forever, never showing the report that was actually completed in the first 90 seconds.  You have to press the "your report" link to get the report to actually show up.

Comment 4

[Michael Morgan [:morgamic]]

We'll have to make proper use of HTTP codes and handle the "we don't have this report" case properly.

Comment 5

[(not currently active) Ted Mielczarek]

I think we can be smarter about this nowadays. Crash IDs now have the date encoded in the last 6 digits as YYMMDD. If the crash id doesn't have a valid date encoded, it's probably old and we no longer have it. If the date is present, and older than the data we have stored, then we can present a 410 Gone or something.

Comment 7

[Ryan Snyder [:ryansnyder] [:rsnyder] [:rysny]]

Attachment: SVN Patch for Ticket #456402

Please perform code review on ticket 465402.  Notes:

1. In javascript before committing, I will change # seconds between calls to 30 seconds and #attempts before giving up to 10.  Currently set to 5 and 3 to accelerate testing.

2. In application/controllers/report.php, lines 183 and 184 are commented out to force code to check test dump directory.  Will be uncommented before committing.

3. URLs for testing in my sandbox:
http://rsnyder.khan.mozilla.org/reporter/report/pending/9e841517-353b-4210-ac41-d8ce72091012 - Fail
http://rsnyder.khan.mozilla.org/reporter/report/pending/1fc2aed1-18d0-4170-9920-2de9a2091001 - Success on 1st Ajax query

Comment 8

[Austin King [:ozten]]

Comment on attachment 408413 [details] [diff] [review]
SVN Patch for Ticket #456402

This patch is looking really good. I like the addition of UUID date detection.

Couple of things:

1) This patch removes the Jobs pending information, which is useful. We want to expose as much information as we know about a crash report.
A crash can be:
1.1) Ready (on filesystem and in DB)
1.2) Too old (not in system anymore)
1.3) Currently being processed
1.4) Failed to Process

application/views/report/pending.php line 52 we should keep the 
We should keep the Queue Info section. (1.3 above)

When we detect too old 1.2 the message should be displayed in the normal page template so the user go navigate to other parts of the system.

*bonus*
We can skip for now, but a future enhancement is that when a crash in is the db, but not the file system (1.4), then often reports.success = FALSE and reports.processor_notes will have a comment that we could display for the user.

2) No change need in application/config/routes.php, probably (per conversation)
3) Extract all JS into pending_reports.js or another appropriate file. Expose a minimal number of JS variables into global namespace. Invoke logic from in page to get vars from PHP as needed
4) *bonus* consider using JSON for ajax call and including an object wrapper, so that you can detect various scenarios... 1.1 - 1.4 above, plug general error handling. Example: response
{ "status": "ready",
  "location": "http://crash-stats.mozilla.com/report/index/9e841517-353b-4210-ac41-d8ce72091011"}
  or
  { "status": "error",
  "message": "Crash Report from 9/22/2006 is no longer in the system."}
etc

Comment 9

[Austin King [:ozten]]

More context on report.success column:

This goes from:
no row for UUID
success = NULL
success = TRUE or success = FALSE

related table jobs which is how a crash gets queued up for processing by UUID.

Comment 10

[Ryan Snyder [:ryansnyder] [:rsnyder] [:rysny]]

Attachment: SVN Patch #2 for Ticket #456402

Thanks Austin.  Here's patch #2, which includes the following changes:

1. Re-added Queue Info section to report/pending.php
2. "Too old" message now being displayed on the page.
3. JS extracted.
4. AJAX calls now returning JSON.

The enhancement to display reports.processor_notes should probably be filed as a separate ticket.  (Trying to keep this iteration small.)

Comment 11

[Austin King [:ozten]]

Comment on attachment 408684 [details] [diff] [review]
SVN Patch #2 for Ticket #456402

Patch looks great!

Comment 12

[Ryan Snyder [:ryansnyder] [:rsnyder] [:rysny]]

Thanks Austin. Committing files.

==

Sending        webapp-php/application/controllers/report.php
Sending        webapp-php/application/models/report.php
Sending        webapp-php/application/views/report/pending.php
Sending        webapp-php/css/screen.css
Adding  (bin)  webapp-php/img/ajax-loader.gif
Adding         webapp-php/js/socorro/pending.js
Transmitting file data ......
Committed revision r1408.

Comment 13

[Ryan Snyder [:ryansnyder] [:rsnyder] [:rysny]]

Oops. Forgot to adjust call times. Will now make an ajax call every 30 seconds for up to 10 attempts.

==

Sending        webapp-php/application/controllers/report.php
Sending        webapp-php/application/views/report/pending.php
Sending        webapp-php/js/socorro/pending.js
Transmitting file data ...
Committed revision r1409.