Bug #20203: API server returns 200 OK when it can't cache a document - Arvados

Actions

Copy link

Bug #20203

closed

API server returns 200 OK when it can't cache a document

Added by Brett Smith almost 2 years ago. Updated over 1 year ago.

Status:

Resolved

Priority:

Normal

Assigned To:

Tom Clegg

Category:

API

Target version:

Development 2023-04-26 sprint

Story points:

1.0

Release:

Arvados 2.6.1

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 open — 1 closed)

Related issues 1 (0 open — 1 closed)

Actions

Copy link

Updated by Brett Smith almost 2 years ago

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

Actions

Copy link

Updated by Peter Amstutz over 1 year ago

Story points set to 1.0
Description updated (diff)

Actions

Copy link

Updated by Peter Amstutz over 1 year ago

Target version changed from Future to To be scheduled

Actions

Copy link

Updated by Peter Amstutz over 1 year ago

Target version changed from To be scheduled to Development 2023-04-26 sprint

Actions

Copy link

Updated by Tom Clegg over 1 year ago

Assigned To set to Tom Clegg

Actions

Copy link

Updated by Tom Clegg over 1 year ago

Status changed from New to In Progress

Actions

Copy link

Updated by Tom Clegg over 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

Copy link