Comment 2 for bug 1433384

I can reproduce this with gccgo on amd64 as well:

----------------------------------------------------------------------
FAIL: tracker_test.go:369: com_juju_juju_worker_leadership_test.TestWaitMinionBecomeMinion.pN56_github.com_juju_juju_worker_leadership_test.TrackerSuite

tracker_test.go:468:
    c.Fatalf("got unexpected readiness: %v", ticket.Wait())
... Error: got unexpected readiness: true

----------------------------------------------------------------------
PASS: tracker_test.go:406: com_juju_juju_worker_leadership_test.TestWaitMinionNeverBecomeMinion.pN56_github.com_juju_juju_worker_leadership_test.TrackerSuite 0.126s
OOPS: 12 passed, 1 FAILED
--- FAIL: TestPackage (0.60 seconds)
FAIL
exit status 1
FAIL github.com/juju/juju/worker/leadership 1.308s

And even with gc/amd64:

----------------------------------------------------------------------
FAIL: tracker_test.go:369: TrackerSuite.TestWaitMinionBecomeMinion

tracker_test.go:375:
    // Check the first ticket stays open.
    assertWaitMinion(c, tracker, false)
tracker_test.go:468:
    c.Fatalf("got unexpected readiness: %v", ticket.Wait())
... Error: got unexpected readiness: true

----------------------------------------------------------------------
PASS: tracker_test.go:406: TrackerSuite.TestWaitMinionNeverBecomeMinion 0.125s
OOPS: 12 passed, 1 FAILED
--- FAIL: TestPackage (0.56 seconds)
FAIL
exit status 1
FAIL github.com/juju/juju/worker/leadership 0.723s

It doesn't happen 100% of the time, but it happens fairly often. I believe the underlying cause is the very short timeout picked in refreshes() - somewhere around a few nanoseconds. I'm investigating a possible fix.