Commits on Nov 2, 2019

1. Cleanup Concurrent RepositoryData Loading (elastic#48329) …

   The loading of `RepositoryData` is not an atomic operation.
   It uses a list + get combination of calls.
   This lead to accidentally returning an empty repository data
   for generations >=0 which can never not exist unless the repository
   is corrupted.
   In the test elastic#48122 (and other SLM tests) there was a low chance of
   running into this concurrent modification scenario and the repository
   actually moving two index generations between listing out the
   index-N and loading the latest version of it. Since we only keep
   two index-N around at a time this lead to unexpectedly absent
   snapshots in status APIs.
   Fixing the behavior to be more resilient is non-trivial but in the works.
   For now I think we should simply throw in this scenario. This will also
   help prevent corruption in the unlikely event but possible of running into this
   issue in a snapshot create or delete operation on master failover on a
   repository like S3 which doesn't have the "no overwrites" protection on
   writing a new index-N.
   
   Fixes elastic#48122

   

   original-brownbear committed Nov 2, 2019
   Configuration menu

   • View commit details
   • Copy full SHA for f133ba7
   • Browse repository at this point

   Copy the full SHA

   f133ba7 View commit details

   Browse the repository at this point in the history