[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:
  davidsarah             |     Status:  new
         Type:  defect   |  Milestone:  1.9.1
     Priority:  major    |    Version:  1.9.0
    Component:  code-    |   Keywords:  assertion error retrieve mutable
  mutable                |  regression
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------
Changes (by zooko):

 * cc: zooko (added)
 * milestone:  undecided => 1.9.1


Old description:

> Reported by Stuart Card:
>
> {{{
> c:\allmydata-tahoe-1.9.0-rebuild\src\allmydata\mutable\retrieve.py, line
> 502 in _activate_enough_peers
> 500    # XXX: don't just drop the Deferred. We need error-reporting
> 501    # but not flow-control here.
> 502    assert len(self._active_readers) >= self._required_shares
>
> _active_readers    List instance @ 0x3510850
> _required_shares   1
> }}}
>
> This was seen with a 1.9.0 client connected to an LAE storage server
> using an S3 backend (on the ticket999-S3-backend branch), with 1/1/1
> encoding parameters. It seems as though the client shouldn't have
> reported an error in this way even if it was caused by the server.
>
> The assertion failure, at
> [source:src/allmydata/mutable/retrieve.py#L502], is in code that changed
> in 1.9.0, so it might be a regression.

New description:

 Reported by Stuart Card:

 {{{
 c:\allmydata-tahoe-1.9.0-rebuild\src\allmydata\mutable\retrieve.py, line
 502 in _activate_enough_peers
 500    # XXX: don't just drop the Deferred. We need error-reporting
 501    # but not flow-control here.
 502    assert len(self._active_readers) >= self._required_shares

 _active_readers    List instance @ 0x3510850
 _required_shares   1
 }}}

 This was seen with a 1.9.0 client connected to an LAE storage server using
 an S3 backend (on the ticket999-S3-backend branch), with 1/1/1 encoding
 parameters. It seems as though the client shouldn't have reported an error
 in this way even if it was caused by the server.

 The assertion failure, at
 [source:trunk/src/allmydata/mutable/retrieve.py?annotate=blame&rev=5358#L507
 retrieve.py line 507], is in code that changed in 1.9.0, so it might be a
 regression.

--

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