-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Data race between test and source code #1080
Comments
Okay, looked at this a bit and convinced myself that this is only a bug in the test code, and not a real bug. In short:
I do not think this is high priority since I'm pretty confident this is only a test bug, but probably the best solution here would be to change the multipart writer to instead be a multi-part reader that pulls on |
I don't quite understand this, but it seems like there is a semantic error in |
This was flagged as an issue against the testify repo here: stretchr/testify#1597 |
Potential workaround PR to make CI green by disabling race detection for that one test: #1082 |
Is it not? Calling
|
Good find on the testify issue! Disabling race detection for this one seems okay to me 👍 |
Ah, OK, I didn't quite realize this. I thought the signature of the race condition indicated that the writer closing was concurrent with the mock test assertion function being called. You wrote this earlier:
You used the word simultaenously here. However, if |
See #1079 for an example.
Run
go test -race ./...
on main to reproduce.The data race seems to come from tests using reflection for mocking, and production code doing other stuff. There appears to be no data race within the production code, only between test and production code.
I traced the first occurrence back to ad1b36a#diff-0a603732f0f49068408f58001aca08acd789cc8f3c1abb75db951824fe681ca5.
The text was updated successfully, but these errors were encountered: