Project

General

Profile

Actions

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.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
API
Story points:
1.0
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.


Subtasks 1 (0 open1 closed)

Task #20322: Review 20203-rails-cacheResolvedTom Clegg04/14/2023Actions

Related issues

Related to Arvados - Idea #20187: Cache discovery doc in memory in controllerResolvedTom Clegg03/15/2023Actions
Actions #1

Updated by Brett Smith about 1 year ago

  • Related to Idea #20187: Cache discovery doc in memory in controller added
Actions #3

Updated by Peter Amstutz about 1 year ago

  • Story points set to 1.0
  • Description updated (diff)
Actions #4

Updated by Peter Amstutz about 1 year ago

  • Target version changed from Future to To be scheduled
Actions #5

Updated by Peter Amstutz about 1 year ago

  • Target version changed from To be scheduled to Development 2023-04-26 sprint
Actions #6

Updated by Tom Clegg about 1 year ago

  • Assigned To set to Tom Clegg
Actions #7

Updated by Tom Clegg about 1 year ago

  • Status changed from New to In Progress
Actions #8

Updated by Tom Clegg about 1 year ago

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?).

Actions #9

Updated by Brett Smith about 1 year ago

Tom Clegg wrote in #note-8:

20203-rails-cache @ 313c0242e956ee4d97cfc9c7080daeaf42475164 -- developer-run-tests: #3600

This is good to merge, thanks.

Actions #10

Updated by Tom Clegg about 1 year ago

  • Status changed from In Progress to Resolved
Actions #11

Updated by Peter Amstutz about 1 year ago

  • Release set to 62
Actions

Also available in: Atom PDF