Issues
SPIKE: Investigate and define latest cache-enabled OKAPI migration steps
Won't Do
CSP Rejection Details
None
CSP Request Details
None
CSP Approved
None
Description
Environment
None
Potential Workaround
None
Attachments
1
Checklist
hideTestRail: Results
Details
Assignee
Taras TkachenkoTaras TkachenkoReporter
Taras TkachenkoTaras TkachenkoPriority
P3Story Points
0Development Team
FolijetTestRail: Cases
Open TestRail: CasesTestRail: Runs
Open TestRail: Runs
Details
Details
Assignee
Taras Tkachenko
Taras TkachenkoReporter
Taras Tkachenko
Taras TkachenkoPriority
Story Points
0
Development Team
Folijet
TestRail: Cases
Open TestRail: Cases
TestRail: Runs
Open TestRail: Runs
Created January 28, 2020 at 2:36 PM
Updated November 8, 2021 at 2:16 PM
Resolved February 13, 2020 at 10:09 AM
Activity
Show:
Ann-Marie BreauxFebruary 13, 2020 at 10:09 AM
Hi and - Mark Veksler confirmed that there is enough investigation of the okapi caching, and nothing further is needed now. He asked that I close this issue as not needed. If needed in the future, we'll open a new issue. Thank you!
It is required to clarify the following questions:
Does new OKAPI support per-request cache disable option that can be switched ON via HTTP header.
Does stripes-connect manifest config support custom HTTP headers and if yes then how to pass it and in which config section.
If OKAPI cache is not configurable in request itself then we should find out how can we switch cache off at all.
Then if Points 1 and 2 is true we should review all our manifest configs in all the UI modules to define which of them require cache to be switched off and disable it for those requests.
In case it's helpful: Here is a file change in git: https://github.com/folio-org/okapi/pull/879/files, plus see attached notes