web client: non-hatch white screen issues

Bug #1768947 reported by Kathy Lussier on 2018-05-03
66
This bug affects 13 people
Affects Status Importance Assigned to Milestone
Evergreen
Medium
Unassigned

Bug Description

I'm starting this bug to see if we can begin to identify the source of web client white screen issues that are unrelated to hatch. In my experience, these problems are hard to reproduce and are usually resolved after clearing cookies from the browser.

In the latest instance of this issues, we saw the following message in the browser console:

Constraint error: (201) Duplicate keys are not allowed, index: Setting.pkSetting, key: "circ.staff_client.receipt.notice_text"

I know I've seen other errors when this issue occurs. Maybe if we can begin documenting them, we might find out what's causing the white screens.

Rosie Le Faive (rlefaive) wrote :

We're seeing white screens in the web client. (not completely white. the menu bar loads, but the rest is white). It happens when we try to load any page - records, reports, acquisitions, etc. The console says:

10:36:46.063 opensrf_ws.js:46 pending count 1
10:36:46.094 opensrf_ws.js:72 pending count 1
10:37:07.686 The FetchEvent for "https://[server]/eg/staff/reporter/legacy/main" resulted in a network error response: an object that was not a Response was passed to respondWith().

The console error always mentions the URL that was tried to access - it's not fixed.

I can usually resolve it by reloading the page 1-5 times.

Rosie Le Faive (rlefaive) wrote :

(forgot to add): clearing the browser cache did not help. Restarting evergreen did not help, either.

Terran McCanna (tmccanna) wrote :

Another error that we've seen happen a few times (it happened to me on Firefox once) was that the browser's local database became corrupted. I don't have the exact wording, but the browser console gave an error referring to the database. I wrote up instructions for deleting the database here:

https://pines.georgialibraries.org/dokuwiki/doku.php?id=circ:workstations:troubleshooting#deleting_the_local_database

Changed in evergreen:
status: New → Confirmed
Remington Steed (rjs7) wrote :

I frequently see the whitescreen when loading the web client in Firefox after not using it for a few days. No interesting errors in the console. In fact, it doesn't even try to load any JS or CSS, except bootstrap. Here's a paste of the console output:

https://pastebin.com/ZAd8j3sQ

A simple refresh (F5) fixes it. That triggers loading all the JS and CSS. It also has slightly different output regarding the auth process (near the bottom, look for "egAuth found no valid authtoken"). Here's the paste of that output:

https://pastebin.com/6gsp5uuW

John Amundson (jamundson) wrote :

I've attached a screenshot of the console output on a WSOD experienced today.

Training Web Client running 3.0.7. Google Chrome. Hatch not installed.

This was "fixed" by clearing cookies.

The screenshot does not show the console set to "All Levels". I will make sure any future reports include all levels.

Kathy Lussier (klussier) wrote :

Adding a note that the URL in that Console log appears to be http://google.github.io/lovefield/error_lookup/src/error_lookup.html?c=201&p0=Setting.pkSetting&p1=%22circ.staff.client.receipt.event_text%22, which, when followed, points to the same Duplicate keys error that was in the original bug description.

Jeff Davis (jdavis-sitka) wrote :

We've had several reports of whitescreen issues since upgrading to 3.1. I'm still gathering information, but "Cannot connect to offline DB" with a link to the duplicate keys error seems to be the most common form.

Clearing cookies and site data seems to be effective as a workaround, but cumbersome (there may not be staff on-hand to re-register a workstation afterward, for example).

Changed in evergreen:
importance: Undecided → Medium
Kathy Lussier (klussier) on 2018-06-01
tags: added: webstaffblocker
Jeff Davis (jdavis-sitka) wrote :

I performed a checkin, a checkout, then hit F1 to retrieve a patron by barcode, at which point I got a white screen. Console logs show our most common error:

Cannot connect to offline DB: Error: http://google.github.io/lovefield/error_lookup/src/error_lookup.html?c=201&p0=Object.pkObject&p1=%5B%22ccs%22%2C%222%22%5D

Constraint error: (201) Duplicate keys are not allowed, index: Object.pkObject, key: ["ccs","2"]

IndexedDB > offline > CacheDate shows several datatypes (acpl, ccs, ccm) apparently cached twice. Digging through IndexedDB > offline > Object, I found ccs values repeated multiple times, e.g. object IDs 321 and 345 both contained value {type:"ccs",id:"2"}.

I'll attach some screenshots of what I'm seeing under IndexedDB in Chrome dev tools.

Bill Erickson (berick) wrote :

Some stuff from IRC:

https://github.com/google/lovefield/issues/172#issuecomment-256284033 (and reading down)

https://github.com/google/lovefield/blob/master/docs/spec/03_life_of_db.md#32-multi-process-connection

Multiple connections across tabs can lead to data inconsistency.

Consider moving lovefield actions into a shared webworker / serviceworker.

Jeff Davis (jdavis-sitka) wrote :

It may be possible to reproduce the offline DB duplicate keys error with the following steps:

(1) Retrieve a patron.
(2) Open Checkin in a new tab and check in an item
(3) In your first tab, check out the item to that patron.
(4) In the same tab, hit F1 to search for patron by barcode.

In my environment, this consistently results in a partial white screen (menu bars load but nothing else) with a "Cannot connect to offline DB" error that links to a duplicate keys error message. The error may be more likely to occur in an environment with a full dataset, as opposed to just concerto data.

Bill Erickson (berick) wrote :

I was able to reproduce with Jeff's steps on a test system.

Here's a patch that allows the page to continue rendering even when the offline DB is in a bad state. It logs the error, then carries on. This is only a stop-gap if we need to buy time to fix the real issue! If the DB has dupe keys, the offline interface will not work. Note I have not tested this on every interface, I've only confirmed it allows a handful of UI's to complete loading.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1768947-ignore-offline-db-errors

Jeff Davis (jdavis-sitka) wrote :

Bill's patch works for me too in limited testing. After following the steps to reproduce, I still see the offline DB error, but the UI appears to load properly.

The patch adds a console error indicating that the offline DB is corrupt and needs to be reset. Would it make sense to add a notification in the UI (like a status indicator in the menu bar) to make ordinary users aware that offline needs to be dealt with?

I just got the following whitescreen error - I do not have hatch installed on my machine.

Steps to replicate

Log in as one user -> open check in screen -> modifify columns -> save columns -> menu -> change operator -> enter new username / password -> open check in screen -> whitescreen (see screenshot)

try to refresh - try to reopen check in - same white screen

Click Home -> Reopen Check in -> check in loads

Bill Erickson (berick) wrote :

Opened bug #1775719 for the IndexedDB issues.

Scott Thomas (scott-thomas-9) wrote :

After months of no white screen problems, all of the libraries in our consortium started seeing it today. Any ideas as to why this would start appearing suddenly at all libraries? We did not make any changes recently.

Scott

Bill Erickson (berick) wrote :

Until the fix for bug #1775719 is merged, I'm going to assume that's the problem. However, Javascript console error logs are always appreciated in case other causes for the white screen issue still exist.

Bill Erickson (berick) wrote :

Just noting that bug #1775719 is now merged and back-ported. Since there are no other leads to follow on this bug, I'm going to close it as a duplicate. Users experiencing continued issues after running the code from bug #1775719 should open a new bug report with details.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.