UI presents misleading "Error: server is down" message when server is clearly up

Description

Summary: Stripes presents an error message, “Error: Server is down” when it is clear the server is up because we can see others in the same office using it just fine, opening it in an incognito window works just fine, and clearing cache and cookies works just fine.

CSP Request Details

Describe issue impact on business Users are unable to authenticate to the FOLIO UI. What institutions are affected? (field “Effected Institutions” in Jira to be populated) Trinity College Cambridge National Library of Australia Pontifica Universidad Javeriana Universidad EAFIT University of Canterbury Douglas College GBV What is the workaround if exists? Clear browser cache, or use an incognito window What areas will be impacted by fix (i.e. what areas need to be retested) UI login Brief explanation of technical implementation and the level of effort (in workdays) and technical risk (low/medium/high) Thoroughly validate the shape of data pulled from storage and do not proceed when data is incomplete. LOE is less than 1 day. Risk is low. Brief explanation of testing required and level of effort (in workdays). Provide test plan agreed with by QA Manager and PO. Validate that users can authenticate. LOE is less than 1 day. What is the roll back plan in case the fix does not work? Revert to the previous release of stripes, which will revert to the previous release of stripes-core.

CSP Rejection Details

None

Potential Workaround

None

Checklist

hide

Activity

Show:

Julian Ladisch December 6, 2024 at 10:17 PM

Bumping release from Q CSP#7 to Q CSP#8.

Q CSP#7 comes with stripes 9.1.6 and stripes-core 10.1.2: https://github.com/folio-org/platform-complete/blob/R1-2024-csp-7/package.json#L71

Zak Burke November 14, 2024 at 8:20 PM

localforage is getting into a state where the okapiSess object contains nothing but { tokenExpiration { atExpires, rtExpires } }. This causes stripes to attempt to resume a session, a process that fails when validateUser() chokes accessing okapiSess.user.id since user is null.

I will fix this in two phases:

  1. quick fix: evaluate an existing session more thoroughly so that only a “full” session can be resumed; a sparse session (i.e. one that is empty save for tokenExpiration data) will be treated as an empty session.

  2. thorough fix: details at

Done

Details

Assignee

Reporter

Priority

Story Points

Sprint

Development Team

Stripes Force

Fix versions

Release

Quesnelia (R1 2024) Service Patch #8

RCA Group

TBD

CSP Approved

Yes

Affected Institution

GBV
National Lib of Australia
OTHER
Trinity College

TestRail: Cases

Open TestRail: Cases

TestRail: Runs

Open TestRail: Runs
Created November 11, 2024 at 8:43 PM
Updated December 9, 2024 at 3:43 PM
Resolved November 22, 2024 at 7:04 PM
TestRail: Cases
TestRail: Runs