assertion failure 'assert len(self._active_readers) >= self._required_shares' in mutable retrieve

[davidsarah]

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 retrieve.py line 507​, is in code that changed in 1.9.0, so it might be a regression.

[davidsarah]

HTML traceback

[davidsarah]

On 31/12/11 01:42, Stuart W. Card wrote:

On 12/30/2011 7:24 PM, David-Sarah wrote:

On 30/12/11 22:10, Stuart W. Card wrote:

... The second actual error was while attempting (for my first time) to run from the UI the checker operations. As the directory and its contents are small, I didn't worry about "expensive", and checked all 4 boxes. It popped a Python exception, in Foolscap/Twisted.

Again, the HTML file is in the attached ZIP archive.

It looks from the traceback in CheckOpsAllBoxesChecked-Exception.htm as though that error is either caused by a client-side problem that isn't specific to the S3 backend, or is being misreported by the client. I've filed <​https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1648> for it.

Does the error always happen for that directory? If yes, does it happen with Tahoe-LAFS 1.8.3?

I just tried it twice more, it appeared to work fine: gave me a bunch of JSON that I don't yet know enough about Tahoe internals to grok.

I never got 1.8.3 working on this particular box. [...]