id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc,launchpad_bug 902,network failure => internal TypeError,zooko,,"I was uploading a file when the local telco monopoly decided to turn off my phone and DSL for a few minutes. My {{{tahoe cp}}} command-line then reported {{{ValueError: too many value to unpack}}} on this line of code: {{{ def set_shareholders(self, (used_peers, already_peers), encoder): }}} It reports that this line is on line 753 of {{{immutable/upload.py}}}. The version is: allmydata-tahoe: 1.5.0-r4054, foolscap: 0.4.2-zsetupztime, pycryptopp: 0.5.15, zfec: 1.4.5, Twisted: 8.2.0, Nevow: 0.9.31-!r15675, zope.interface: 3.1.0c1, python: 2.5.4, platform: Darwin-8.11.1-i386-32bit, sqlite: 3.1.3, simplejson: 2.0.9, argparse: 0.8.0, pyOpenSSL: 0.9, pyutil: 1.5.1, zbase32: 1.1.0, setuptools: 0.6c12dev, pysqlite: 2.3.2 Line 753 of {{{immutable/upload.py}}} at version 4054 is [source:src/allmydata/immutable/upload.py@4054#L753]. That method is called from only one place, [source:src/allmydata/immutable/upload.py@4054#L723 line 720], which means that [source:src/allmydata/immutable/upload.py@4054#L725 locate_all_shareholders()] must have returned something which wasn't a tuple containing at least two values. Looking at {{{locate_all_shareholders()}}} I see that what it returns is whatever [source:src/allmydata/immutable/upload.py@4054#L145 Tahoe2PeerSelector.get_shareholders()] returned. (This fact may not be obvious to you if you aren't familiar with the Twisted Deferreds but it should be obvious to you if you are.) It looks like {{{get_shareholders()}}} returns whatever is returned by [source:src/allmydata/immutable/upload.py@4054#L225 Tahoe2PeerSelector._loop()]. There are three (non-recursive) {{{return}}} statements from {{{_loop()}}}. [source:src/allmydata/immutable/upload.py@4054#L238 The first one] returns a 2-tuple, [source:src/allmydata/immutable/upload.py@4054#L254 the second one] returns the return-value of [source:src/allmydata/immutable/upload.py@4054#L313 Tahoe2PeerSelector._got_response()], and [source:src/allmydata/immutable/upload.py@4054#L311 the third one] returns {{{self.use_peers}}}. Wait a second, that can't be right -- {{{self.use_peers}}} [source:src/allmydata/immutable/upload.py@4054#L167 is a set of servers] not a 2-tuple. When does {{{_loop()}}} reach this return statement? Reading the control flow, it does so when 1. [source:src/allmydata/immutable/upload.py@4054#L240 there are no uncontacted servers], and 2. [source:src/allmydata/immutable/upload.py@4054#L257 there are no servers in the ask-again set], and 3. [source:src/allmydata/immutable/upload.py@4054#L278 there are no servers in the and-then-ask-yet-again set], and 4. [source:src/allmydata/immutable/upload.py@4054#L287 we already placed enough shares to be happy]. So I guess this is a rare situation, in which we've placed enough shares to be happy simultaneously as all of our servers disappeared. (Also the status message {{{""Placed all shares""}}} seems slightly wrong.) I guess the next step is to write a unit test of this situation. I assume that there isn't one, since if there were it would fail. :-) But I'm going to stop here and work on other priorities (#778) now, so if anyone else wants to fix this then please go ahead! ",defect,closed,major,1.7.0,code-peerselection,1.5.0,fixed,reliability easy upload,francois@…,