[tahoe-lafs-trac-stream] [tahoe-lafs] #1739: servers-responding list is wrong

[tahoe-lafs]

#1739: servers-responding list is wrong
--------------------+------------------------
 Reporter:  warner  |          Owner:  warner
     Type:  defect  |         Status:  new
 Priority:  minor   |      Milestone:  soon
Component:  code    |        Version:  1.9.1
 Keywords:          |  Launchpad Bug:
--------------------+------------------------
 I ran into a bug, hunted it down, and squashed it. Here's the
 description and the patch:

 If a server did not respond to the pre-repair filecheck, but did
 respond to the repair, that server was not correctly added to the
 {{{RepairResults.data["servers-responding"]}}} list. (This resulted from
 a buggy usage of {{{DictOfSets.union()}}} in filenode.py).

 In addition, servers to which filecheck queries were sent, but did
 not respond, were incorrectly added to the servers-responding list
 anyawys. (This resulted from code in the checker.py not paying
 attention to the 'responded' flag).

 The first bug was neatly masked by the second: it's pretty rare to
 have a server suddenly start responding in the one-second window
 between a filecheck and a subsequent repair, and if the server was
 around for the filecheck, you'd never notice the problem. I only
 spotted the smelly code while I was changing it for IServer cleanup
 purposes.

 I added coverage to test_repairer.py for this. Trying to get that
 test to fail before fixing the first bug is what led me to discover
 the second bug. I also had to update test_corrupt_file_verno, since
 it was incorrectly asserting that 10 servers responded, when in
 fact one of them throws an error (but the second bug was causing it
 to be reported anyways).

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1739>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage