You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Testify mocks are currently prone to data races when supplied a pointer argument (that may be concurrently updated elsewhere).
In several instances of our code, we have started seeing data races when running go test -race that originate from testify code. More specifically these data races occur whenever a mock pointer argument is concurrently modified. The reason being that Arguments.Diff uses the %v format specifier to get a presentable string for the argument. This also traverses the pointed-to data structure, which would lead to the data race.
We did not see these issues earlier, but they started appearing lately after we upgraded to go 1.22. Not sure if that is a coincidence, but maybe performance improved in such a way that these data races suddenly started surfacing.
We need to test our code for race conditions with go test -race, and we cannot have testify be the offender of data races.
A PR to resolve the issue is suggested in #1598.
(It should be noted that it is heavily inspired by #1229, but since that PR hasn't seen any updates in over a year I decided to start fresh).
Description
Testify mocks are currently prone to data races when supplied a pointer argument (that may be concurrently updated elsewhere).
In several instances of our code, we have started seeing data races when running
go test -race
that originate from testify code. More specifically these data races occur whenever a mock pointer argument is concurrently modified. The reason being thatArguments.Diff
uses the%v
format specifier to get a presentable string for the argument. This also traverses the pointed-to data structure, which would lead to the data race.We did not see these issues earlier, but they started appearing lately after we upgraded to go 1.22. Not sure if that is a coincidence, but maybe performance improved in such a way that these data races suddenly started surfacing.
We need to test our code for race conditions with
go test -race
, and we cannot have testify be the offender of data races.A PR to resolve the issue is suggested in #1598.
(It should be noted that it is heavily inspired by #1229, but since that PR hasn't seen any updates in over a year I decided to start fresh).
Step To Reproduce
See test case in suggested fix PR: #1598
Expected behavior
The unit test in #1598 passes when running with
go test -race
.Actual behavior
The unit test fails with a data race:
The text was updated successfully, but these errors were encountered: