Bug #12791

[API] fix race between arrival of trash time and next sweep

Added by Ward Vandewege about 1 year ago. Updated about 1 year ago.

Status:
New
Priority:
Normal
Assigned To:
-
Category:
-
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Story points:
-

Description

As evidenced in #12790, there exists a race between when the trash time arrives for a collection, and the next trash sweep. During that period, accessing a collection by PDH results in a 401 ("Expired permission signature"). Tom put it like this:

Even with this config fixed, there's obviously a race condition that we need to fix between when trash time arrives and the next sweep. Here it's just glaringly obvious because the race window is forever.

In #12790 we noticed this problem because trash_sweep_interval was set to 0s.

History

#1 Updated by Ward Vandewege about 1 year ago

  • Status changed from New to In Progress

#2 Updated by Ward Vandewege about 1 year ago

  • Description updated (diff)
  • Status changed from In Progress to New

#4 Updated by Ward Vandewege about 1 year ago

  • Description updated (diff)

#5 Updated by Tom Clegg about 1 year ago

is_trashed is a cache of trash_at<now. When it's out of date:
  • when getting a collection by PDH and there are multiple candidates, we might accidentally choose one that expires soon (or in the past), and give the client signatures that expire sooner than necessary (or are already expired and therefore completely useless)
  • when getting a collection by UUID, and include_trash is false, we might return a trashed collection anyway, which is wrong
  • when getting a list of collections, and include_trash is false, we might include some trashed collections in the results
  • when getting a list of collections, and include_trash is false, we might include some trashed collections in the items_available count

Also available in: Atom PDF