[tahoe-lafs-trac-stream] [tahoe-lafs] #1689: assertion failure

[tahoe-lafs]

#1689: assertion failure
-------------------------+-------------------------------------------------
     Reporter:  jg71     |      Owner:  nobody
         Type:  defect   |     Status:  new
     Priority:           |  Milestone:  undecided
  critical               |    Version:  1.9.1
    Component:  unknown  |   Keywords:  tahoe-check verify regression
   Resolution:           |  assertion error mutable
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by warner):

 More findings:

 * doing a non-deep {{{tahoe check --repair}}} gets the same failure, but
 gets a webapi 500 Internal Server Error (but successfully repairs the
 file, I think).
 * the Retrieve half of the repair is doing a mapupdate with MODE_READ
 (which doesn't try to fetch the privkey), but it needs to be using
 MODE_WRITE (to force a privkey fetch)
 * the mapupdate does a few queries that do, in fact, get the privkey, but
 the responses arrive too late for the Publish to use them.

 Maybe there's a race condition, and larger files allow mapupdate to win
 the race and get the privkey in time for Publish to use it, but small
 (empty) files allow the Publish to start too early. The MODE_READ is
 definitely wrong, though: not only does it not bother to get the privkey
 in that case, it also doesn't search as hard to find all shares
 (MODE_WRITE tries harder, to avoid leaving any share behind at an old
 version).

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1689#comment:6>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage