1
95%
master: 95%

Ran 08 Apr 2016 07:24AM UTC

Files 209

Run time 8s

Badge

Embed ▾

Committed 08 Apr 2016 07:24AM UTC coverage: 91.74% (+0.1%) from 91.641%

Job # 1084.1

Build Type

push

travis-ci

Committed by Brian Warner

Commit Message

test/common: add a slight stall in tearDown

With the new Foolscap-0.11.0 (which changed the way connections are
established), I'm seeing DirtyReactorErrors getting thrown by
allmydata.test.test_system.SystemTest.test_filesystem_with_cli_in_subprocess
, on a host that has three IP addresses (one is 127.0.0.1, two is wifi,
three is a VPN). The test itself is getting skipped because bin/tahoe
isn't in the expected place, but by that point, the nodes have already
been launched and have established connections over one of the three
hints (probably 127.0.0.1). The test terminates so quickly that the
connections to the other two addresses have not finished being
abandoned. The extra stall seems to give Foolscap enough time to reap
the cancelled connections and makes the DRT go away.

I think an offline test, or maybe one with a single external IP address,
wouldn't hit this case.

Arbitrary stalls are never very satisfactory, of course. Usually there
is some threshold delay value, below which it fails reliably, above
which it works on my own machine (for now). This one is weird: the
threshold seems to be below the resolution of the system clock. Stalling
for one nanosecond was enough to fix the problem, but using a simple
fireEventually() didn't work.

Run Details

49927 of 54422 relevant lines covered (91.74%)

0.92 hits per line

tahoe-lafs / tahoe-lafs / 1084 / 1
95%
master: 95%

README BADGES
x

Markdown

Textile

RDoc

HTML

Rst

Source Files on job 1084.1

tahoe-lafs / tahoe-lafs / 1084 / 1 95% master: 95%

README BADGES x

Markdown

Textile

RDoc

HTML

Rst

Source Files on job 1084.1

tahoe-lafs / tahoe-lafs / 1084 / 1
95%
master: 95%

README BADGES
x