25a63195da
The concurrent gate access test is flaky since it depends on the order of operations of two concurrent goroutines. Despite the heavy bias towards one of the results, it's still possible to end the execution with a closed gate. I believe this case was created to test an earlier implementation where the gate state was stored and mutated internally, so the access had to be protected by a lock. However, the final implementation changed this approach to be only channel-based, so there is no need for this flaky test anymore. |
||
|---|---|---|
| .. | ||
| coordinator.go | ||
| coordinator_test.go | ||
| doc.go | ||
| gate.go | ||
| gate_test.go | ||
| testing.go | ||