funnel icon indicating copy to clipboard operation
funnel copied to clipboard

Server error follow-up with users

Open jace opened this issue 3 years ago • 0 comments

When a user encounters an internal server error, the user deserves a follow-up explaining the resolution. This is currently a flaky process as the user identity must be extracted from the error report, then their email from the database, and then a support request is created in SupportBee. Emails are now scrubbed for private information, so the user is not always identifiable.

Instead, the app could keep its own logs of error reports designed for follow-up. This can be flaky when the failure is fundamental, like a dead database connection, so it's something of a best effort report.

  1. The app errorhandler for 500 errors (or Coaster-logging type handler) collects all relevant information and pushes it to a background job. Caveat: This can be a large payload, but at least the job will remain in queue when the database is down. Alt: process in-line, but in an on-close handler.

  2. Make a UserReport or ErrorReport model to which the error is logged. This model needs two parts: a private field that is visible only to developers (traceback, etc), and a user-friendly text field that has a user-facing description (such as the URL at which the error occurred).

  3. Optionally, make this model use Commentset, to allow a conversation between user and developer.

  4. Raise a notification either when the report is received, or when there is a resolution. The latter may be a more prudent time to notify the user.

  5. This system works for logged-in users. With anonymous users there is no way to contact them, unless we tag an identifier into a browser cookie and show a message when the browser appears again. However, the anon user tracking system in Hasjob hasn't worked well due to bot traffic and could be a breaking point again here.

  6. Some users are on the threshold, such as when there's an error on a login or registration form. In this case we have contact info from the form data, but no user account to tag a report to. While the UserReport model can have fields for contact info, the notification system can't process that (currently). This will take some reworking.

  7. The SiteAdmin model will need an additional is_site_developer flag for permission to access error reports. This is also a pending ask for access to RQ dashboard.

jace avatar Jun 14 '21 19:06 jace

Okay, I like this! :)

geohacker avatar Jun 18 '12 04:06 geohacker

Won't happen now.

sidharthkuruvila avatar Jun 19 '12 13:06 sidharthkuruvila

I mean won't happen till after launch. I'd like to see something up first.

sidharthkuruvila avatar Jun 19 '12 14:06 sidharthkuruvila

Yup, this should be deferred to iteration 2.

jace avatar Jun 19 '12 15:06 jace