TestRunBacklogFailedContinuesDiffApp is racy
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ubuntu-push (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
TestRunBacklogF
kindpool_
// Everything up to here was just set-up.
//
// What we're checking for is that, if a helper launch fails, the
// next one in the backlog is picked up.
c.Assert(
... obtained *click.AppId = &click.
... expected *click.AppId = &click.
This is a race. It's a bit confusing -- and I don't really understand this code -- but it's something like this:
TestRunBacklogF
The test causes the "in, ok := <-pool.chIn" case of the select in loop to be entered twice: the first time the loop goroutine calls handleOne and the second time it just puts the input in backlog.
The test then calls "go s.fakeLauncher.
It's possible to make this fail on 1.4 by putting a small sleep after the send to chDone.
Related branches
- dobey (community): Approve
-
Diff: 126 lines (+45/-6)2 files modifiedlaunch_helper/kindpool.go (+12/-3)
launch_helper/kindpool_test.go (+33/-3)
Changed in ubuntu-push: | |
assignee: | nobody → Samuele Pedroni (pedronis) |
affects: | ubuntu-push → ubuntu-push (Ubuntu) |
Changed in ubuntu-push (Ubuntu): | |
assignee: | Samuele Pedroni (pedronis) → nobody |
Changed in ubuntu-push (Ubuntu): | |
status: | New → Fix Released |
There is a similar ish race in TestRunNthAppTo Backlog: this time, the channel read on the other end of s.pool.Run("fake", input3) races with s.fakeLauncher. done("0" ). If the latter completes first, no job gets onto the backlog and the test fails.