[tahoe-lafs-trac-stream] [tahoe-lafs] #1648: assertion failure 'assert len(self._active_readers) >= self._required_shares' in mutable retrieve

[tahoe-lafs]

#1648: assertion failure 'assert len(self._active_readers) >=
self._required_shares' in mutable retrieve
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  kevan
  davidsarah             |     Status:  new
         Type:  defect   |  Milestone:  1.9.1
     Priority:  major    |    Version:  1.9.0
    Component:  code-    |   Keywords:  assertion error retrieve mutable
  mutable                |  regression review-needed
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------
Changes (by kevan):

 * keywords:  assertion error retrieve mutable regression => assertion error
     retrieve mutable regression review-needed


Comment:

 I made a pull request [https://github.com/warner/tahoe-lafs/pull/3 on
 GitHub]. From the description there:

 > The Retrieve class gets used both for downloading, validating, decoding
 and decrypting remote shares (writing the plaintext to a consumer) and for
 validating remote shares, since the steps to validate the shares of a file
 are a subset of the steps to assemble that file into plaintext. There were
 several assertions throughout the code path used by the verification
 process that didn't take the verification use case into account, since
 they implicitly assumed that having fewer than k active readers was an
 error. This is true in the case of downloading a file, since the Retrieve
 should be aborted with an error before proceeding down this code path in
 that case, but not for a verification, which can sensibly continue with
 fewer than k shares. These commits test that this case is handled
 correctly, remove the assertions so that verification operations with
 fewer than k shares don't fail due to an assertion error, and add code to
 Retrieve._download_current_segment to ensure that the verification
 operation is aborted if all of the shares are corrupt.

 I'm setting 'review-needed'. I guess if we're using GitHub, that means you
 should go look at the pull request. I can attach an equivalent patch to
 this ticket if anyone wants me to do that.

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