Webstaff offline DB connection failures
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Evergreen |
Fix Released
|
High
|
Unassigned |
Bug Description
Evergreen 3.0.beta
Researching comment #5 from this LP comment:
https:/
I recently started seeing many similar errors, generally more focused on org unit settings. E.g.
Constraint error: (201) Duplicate keys are not allowed, index: Setting.pkSetting, key: "lib.timezone"
These errors would prevent pages from loading in the browser client 4 out of 5 times. (I assume there's a race condition there). Deleting the offline indexdb database resolves the issue for a short period of time.
While researching the bug, I found a secondary issue where connection failures to the offline DB resulted in infinite loops in egLovefield.
Fixes to the above en route.
Changed in evergreen: | |
status: | New → Confirmed |
importance: | Undecided → High |
assignee: | nobody → Galen Charlton (gmc) |
Changed in evergreen: | |
status: | Fix Committed → Fix Released |
Fixes pushed:
http:// git.evergreen- ils.org/ ?p=working/ Evergreen. git;a=shortlog; h=refs/ heads/user/ berick/ lp1718301- lovefield- offline- connection- refactor
This resolves the looping issue by replacing the polling with a shared promise, similar to egStartup.go. It improves error logging by collecting error info in the database.connect() reject handler instead of letting the bare exception bubble up to the console.
After applying these changes, the duplicate keys errors are also no longer appearing for me. I'm not entirely sure why, but the 2 main functional differences are the lack of looping while waiting for a connection and that no offline DB connection attempt is made until the first call to egLoveField. connectOrGo( ) is called (which I initially did just to avoid code duplication).
I have confirmed the offline DB connects successfully and callers to connectOrGo are having their resolver functions run. More eyes and testing will definitely be needed, though.