Closed Bug 456402 Opened 13 years ago Closed 12 years ago

Improve user experience for pending reports


(Socorro :: General, task, P1)


(Not tracked)



(Reporter: morgamic, Assigned: ryansnyder)



(Whiteboard: next)


(1 file, 1 obsolete file)

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
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
  if full report wasn't displayed within the allotted time:
     display message disparaging the parentage of the developers, sys admins
  display full report

display full report actually means:
  if success is True:
    display all the information about frames, dumps, etc.
    display the contents of the message column
   #note: message column name to change in the new schema...
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.
Assignee: nobody → aking
Assignee: aking → neilio
Blocks: 411428
Summary: Display better report status on pending page → Improve user experience for pending reports
Assignee: neilio → jsocol
Depends on: 414258
Duplicate of this bug: 414258
We'll have to make proper use of HTTP codes and handle the "we don't have this report" case properly.
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.
Duplicate of this bug: 428291
Priority: -- → P1
Whiteboard: next
Assignee: james → ryan
Attached patch SVN Patch for Ticket #456402 (obsolete) — Splinter Review
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: - Fail - Success on 1st Ajax query
Attachment #408413 - Flags: review?(ozten.bugs)
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.

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": ""}
  { "status": "error",
  "message": "Crash Report from 9/22/2006 is no longer in the system."}
Attachment #408413 - Flags: review?(ozten.bugs) → review-
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.
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.)
Attachment #408413 - Attachment is obsolete: true
Attachment #408684 - Flags: review?(ozten.bugs)
Comment on attachment 408684 [details] [diff] [review]
SVN Patch #2 for Ticket #456402

Patch looks great!
Attachment #408684 - Flags: review?(ozten.bugs) → review+
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.
Closed: 12 years ago
Resolution: --- → FIXED
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.
Component: Socorro → General
Product: Webtools → Socorro
You need to log in before you can comment on or make changes to this bug.