{"push_id":1057136488,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"bb7184163e6b6fcf1c1fbc41fd0000cf59918277","before":"8279d919f32a30a408951bdcb6e4461957b8303c","commits":[{"sha":"bb7184163e6b6fcf1c1fbc41fd0000cf59918277","author":{"email":"32339611df027ade1e4c7ce52fc19d50c05be10e@lothar.com","name":"Brian Warner"},"message":"test/common: add a slight stall in tearDown\n\nWith the new Foolscap-0.11.0 (which changed the way connections are\nestablished), I'm seeing DirtyReactorErrors getting thrown by\nallmydata.test.test_system.SystemTest.test_filesystem_with_cli_in_subprocess\n, on a host that has three IP addresses (one is 127.0.0.1, two is wifi,\nthree is a VPN). The test itself is getting skipped because bin/tahoe\nisn't in the expected place, but by that point, the nodes have already\nbeen launched and have established connections over one of the three\nhints (probably 127.0.0.1). The test terminates so quickly that the\nconnections to the other two addresses have not finished being\nabandoned. The extra stall seems to give Foolscap enough time to reap\nthe cancelled connections and makes the DRT go away.\n\nI think an offline test, or maybe one with a single external IP address,\nwouldn't hit this case.\n\nArbitrary stalls are never very satisfactory, of course. Usually there\nis some threshold delay value, below which it fails reliably, above\nwhich it works on my own machine (for now). This one is weird: the\nthreshold seems to be below the resolution of the system clock. Stalling\nfor one nanosecond was enough to fix the problem, but using a simple\nfireEventually() didn't work.","distinct":true,"url":"https://api.github.com/repos/warner/tahoe-lafs/commits/bb7184163e6b6fcf1c1fbc41fd0000cf59918277"}]}