[tahoe-dev] [tahoe-lafs] #1191: unit test failure: failed to download file with 2 shares on one server and one share on another

[tahoe-lafs]

#1191: unit test failure: failed to download file with 2 shares on one server and
one share on another
------------------------------------+---------------------------------------
     Reporter:  zooko               |       Owner:  Brian Warner <warner@…>         
         Type:  defect              |      Status:  closed                          
     Priority:  major               |   Milestone:  1.8.0                           
    Component:  code-peerselection  |     Version:  1.8β                            
   Resolution:  fixed               |    Keywords:  immutable download              
Launchpad Bug:                      |  
------------------------------------+---------------------------------------

Comment (by zooko):

 By the way there is a generalization that I could make about [attachment
 :do-retire-and-got-share-in-same-tick.dpatch.txt] compared to
 [attachment:1191-fix.diff]. We use state machines to handle asynchronous
 events, so when we want to have some behavior which spans multiple network
 events or timeouts and which has state, we have to store the state
 somewhere and check it in the next step of the state machine. ''But'', we
 should really avoid the state machine paradigm whenever possible, so if we
 have some behavior which spans multiple ticks within one Twisted reactor,
 then we should ''not'' store the state somewhere and check the state in
 the function that we eventually run—we should instead ''pass'' that state
 as an argument to the eventually run function. That's just my opinion,
 man.

 This is not to criticize [attachment:1191-fix.diff]. It is the smallest
 patch that fixes all the known problems, and it is what we're actually
 deploying in 1.8.0, but I wanted to explain why I spent time attempting
 (unsuccessfully) to write [attachment:do-retire-and-got-share-in-same-
 tick.dpatch.txt] instead.

 A related idea that I have is: suppose you have a {{{loop()}}} method (we
 have several) which contains the core of the state machine. Suppose you
 have some new information/some new event to communicate to the state
 machine. Then do ''not'' write down the new event and trigger the state
 machine, like {{{self._no_more_shares = True; eventually(self.loop)}}},
 but instead extend the interface of {{{loop()}}} to accept this event,
 like {{{eventually(self.loop, no_more_shares=True)}}}. That way people
 will not have to think about what happens if the state changes in other
 ways before that {{{eventually(self.loop)}}} happens, such as if there is
 already a different call to {{{loop}}} on the eventual queue. If we hadn't
 needed to consider such potential complications, it would have been easier
 for us to diagnose the issue in this ticket.

-- 
Ticket URL: <http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1191#comment:21>
tahoe-lafs <http://tahoe-lafs.org>
secure decentralized storage