Closed maxcnunes closed 7 years ago
Humm. The tests are failing due race condition. So that Lock is really necessary. Well at least the example I have included should help reproducing the problem.
Thank you! I'm going to provide a fix soon based on your changes. The existent mutex is overloaded and should not be used in the store context.
This should be already fixed in gock@v1.0.5
/ master
. Test it upgrading gock
:
go get -u gopkg.in/h2non/gock.v1
Please, let me know if you're having any issue.
@h2non The hanging still happening for the example I have added.
Oops! Will take a look later today.
@maxcnunes Got some time this morning. What about now? You would need to pull latest gock
version.
Thanks @h2non. It is working now 👍
Nice. Closing this PR. Thank you for reporting the issue!
@h2non This PR wasn't only to issue the bug. I was also adding an example to any other user interested in partially enabling the networking. So, could you please merge it? :)
Yeah, sure. Will do later.
I have some integration tests that I would like to allow real networking for my local server. But any request from that local server should be mocked. With the current version it isn't working because the mocked request will hang up forever. Seems this is the same problem from https://github.com/h2non/gock/issues/18. And following the suggestions from that issue I could get it working. Removing the
mutex.Lock
makes the hanging go away. But I'm not sure this is the right solution. Although I'm also not suremutex.Lock
is really necessary in thatRoundTrip
. At least the real Go implementation doesn't have any mutex.Lock that I could find https://golang.org/src/net/http/transport.go?s=11576:11638#L309