tests: fix potential races with t.Parallel and loops ➿ #3493
Conversation
tekton-robot
added
release-note-none
tekton-robot
added
the
size/S
| @@ -218,6 +218,7 @@ func TestExamples(t *testing.T) { | |||
|
|
|||
| t.Parallel() | |||
| for _, path := range getExamplePaths(t, baseDir) { | |||
| path := path // capture range variable | |||
There was a problem hiding this comment.
Thus is needed because exampleTest called later.. does use t.Parallel()
Following the CommonMistake[1] in Go, for loop and go routines can be a big racey problem. This happens quite easily when using `t.Parallel` in for loop with tests. This fixes possible races by adding a "shadow" var that is evaluated at each iteration and placed on the stack for the goroutine, so each slice element is available to the goroutine when it is eventually executed. [1]: https://github.com/golang/go/wiki/CommonMistakes#using-goroutines-on-loop-iterator-variables Signed-off-by: Vincent Demeester <[email protected]>
vdemeester
force-pushed
the
test-parallel-and-closure
branch
from
3016975
to
0b4c0d9
Compare
| i := i // capture range variable | ||
| td := td // capture range variable |
There was a problem hiding this comment.
I often use i, td := i, td to avoid the compounding pollution
|
(note that this might "fix" some flakey test — or might not 🧇) |
Yeah I am not sure where to put this 🙃 |
There was a problem hiding this comment.
thanks @vdemeester, nice catch 👍
and one other advantage of table driven test is to have them run in parallel, just realizing, we have not been using t.Parallel() in our unit tests except one 😱
grep -r "t.Parallel()" ./pkg/
./pkg//reconciler/pipelinerun/resources/apply_test.go: t.Parallel()
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: pritidesai The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
tekton-robot
added
the
approved
Changes
Following the CommonMistake1 in Go, for loop and go routines can be
a big racey problem. This happens quite easily when using
t.Parallelin for loop with tests.
This fixes possible races by adding a "shadow" var that is evaluated
at each iteration and placed on the stack for the goroutine, so each
slice element is available to the goroutine when it is eventually
executed.
Signed-off-by: Vincent Demeester [email protected]
/kind bug
/area testing
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
See the contribution guide for more details.
Double check this list of stuff that's easy to miss:
cmddir, please updatethe release Task to build and release this image.
Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.
Release Notes