-
-
Notifications
You must be signed in to change notification settings - Fork 231
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
Prevent meck_procs timeouts when stopping #231
Conversation
Hmm... it might be the case that gen_server:stop bypasses sys:suspend, which is what the failed test relies on. |
Interesting fix. This might be the cause of a few hard-to-reproduce Can you reproduce the failed test case on your end? |
That sounds like a good idea! |
Updated! |
Seems the exception is triggered somehow. Maybe try locally and remove the try catch to see which exception is thrown there. Can you reproduce the failing test cases? |
Now tests pass locally. I had accidentally commited some debug-related code. |
Looks good. Can you update the I'd prefer the commit message to be |
5137b18
to
33a91b0
Compare
Done! |
@aronisstav Last minor thing: the changelog entry needs to be under |
When stopping (e.g. due to meck:unload/1), meck_procs restore the original module, which may be a time consuming operation. If a gen_server:call is used for stopping, there's risk of a timeout that will be translated to a confusing error:{not_mocked, ...}. Using gen_server:stop/1 breaks tests, so using an infinity timeout instead.
Sorry, fixed again. |
Thank you! ❤️ |
When stopping (e.g. due to meck:unload/1), meck_procs restore the original module, which may be a time consuming operation.
If a gen_server:call is used for stopping, there's risk of a timeout that will be translated to a confusing error:{not_mocked}.
Using gen_server:stop/1 easily uses an infinity timeout, preventing the issue.
This is fixing a bug where such a time-consuming restoration was causing an end_per_suite operation to fail, confusingly.