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 |
aronisstav
force-pushed
the
patch-1
branch
2 times, most recently
from
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.