Bug #20203
closed
API server returns 200 OK when it can't cache a document
Added by Brett Smith about 1 year ago.
Updated about 1 year ago.
Release relationship:
Auto
Description
If the filesystem underlying the API server's cache is full, it can get into a situation where requests for cached documents return a 200 OK with an empty response.
#20187 is meant to help mitigate this for the discovery document. We should investigate if there are other routes where this can happen, and if possible, return an error code in those cases.
Investigate other uses of the rails cache and see if they are needed any more. Also investigate if we should switch over to a memory cache so it doesn't rely on disk.
- Related to Idea #20187: Cache discovery doc in memory in controller added
- Story points set to 1.0
- Description updated (diff)
- Target version changed from Future to To be scheduled
- Target version changed from To be scheduled to Development 2023-04-26 sprint
- Assigned To set to Tom Clegg
- Status changed from New to In Progress
20203-rails-cache @ 313c0242e956ee4d97cfc9c7080daeaf42475164 -- developer-run-tests: #3600 
The only rails cache usage I could found was
- audit logs cleanup task, #20192
- resetting CurrentApiClient globals (system_user etc) during database#reset
I'm pretty sure the CurrentApiClient code was not working correctly -- database#reset would cause one thread to reset its globals, but not other threads.
I rearranged it so
- when not in test mode, it doesn't call any Rails.cache methods at all
- when in test mode, it still uses the rails cache, but now database#reset resets globals in all threads
This could conceivably fix some flaky behavior in other test suites that use the database reset feature (ahem, wb1?).
- Status changed from In Progress to Resolved
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by