]> git.rkrishnan.org Git - tahoe-lafs/tahoe-lafs.git/commit
immutable repairer: populate servers-responding properly
authorBrian Warner <warner@lothar.com>
Wed, 16 May 2012 23:50:43 +0000 (16:50 -0700)
committerBrian Warner <warner@lothar.com>
Wed, 16 May 2012 23:55:09 +0000 (16:55 -0700)
commit9acf5beebd41320de6dbf5e236244dda3349d1f8
tree920da9648cd324af2ff8bd9358d91a2a82653be5
parent5ec20761edfb74153cb193a9b1772f73326425ba
immutable repairer: populate servers-responding properly

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).
src/allmydata/immutable/checker.py
src/allmydata/immutable/filenode.py
src/allmydata/test/no_network.py
src/allmydata/test/test_repairer.py