Commits on Mar 23, 2024

1. Fix race condition in scan / watch setup …

   I set up a watch by:
   
   1. Scanning all the keys under all of the prefix
   2. Establishing a watch from the revision returned by the scan
   
   To avoid missing data, it's essential that all the scanning is done at
   the *same* revision.  Otherwise, if the scan requires multiple requests,
   and some data is written between the two requests, the second request
   could miss it.
   
   Unfortunately, that's what seemed to be happening.
   
   I was able to track it down by adding a bit more logging of revision
   numbers: each scan used the following revision, rather than using the
   same revision!  Turns out that I had misinterpreted the meaning of the
   `revision` field of the response header.  The documentation says:
   
   > revision is the key-value store revision when the request was applied.
   
   Which is terse, but made me think that:
   
   - If I don't supply a revision in the `RangeRequest` (ie, `revision: 0`) it
      returns the latest revision.
   - If I do supply a revision in the `RangeRequest`, it uses that.
   
   That's not right.  The header `revision` is actually the latest
   revision at the time the request was answered, and has no relation to
   the revision specified in the request.
   
   So the correct thing to do is, on the very first request, to not supply
   a revision - and then use the header `revision` returned *from that
   first request* for all subsequent requests.

   

   barrucadu committed Mar 23, 2024
   Configuration menu

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

   Copy the full SHA

   54dabc0 View commit details

   Browse the repository at this point in the history