Skip to content
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

Getting meck_proc already started errors #217

Open
SoniCoder opened this issue Oct 27, 2020 · 7 comments
Open

Getting meck_proc already started errors #217

SoniCoder opened this issue Oct 27, 2020 · 7 comments

Comments

@SoniCoder
Copy link

Expected behavior

make eunit/junit COVER=1 should pass post OTP 23

Observed behavior

Getting these kinds of errors (with COVER=1) for some unknown reasons that were not coming before OTP 23

::in function meck_proc:start/2 (src/meck_proc.erl, line 93) called as start(put_functions,[passthrough]) **error:{already_started,<0.16752.0>}

This only happens with COVER=1 and succeeds when COVER=1 is not specified

Versions

  • Meck version: hex 0.8.13 (have tried 0.9 as well)
  • Erlang version: OTP 23.1.1

OS: Debian Buster
Erlang OTP 23.1.1 installed(compiled) via. kerl

@eproxus
Copy link
Owner

eproxus commented Feb 17, 2021

Not sure how to reproduce this. What project are you building and how?

@SoniCoder
Copy link
Author

The project is private. However we have noticed that it doesn't always happen (only sometimes perhaps due to some race conditions) and only happens with cover even though we are doing teardown of that module's meck properly using meck:unload() every single time.

@eproxus
Copy link
Owner

eproxus commented Feb 17, 2021

Are you running tests in parallel? This error occurs when there's already a mock started for the module. Alternatively, perhaps you have a cleanup that doesn't always run properly?

@SoniCoder
Copy link
Author

Not specifying any execution order and letting eunit decide everything. Have my cleanup (meck:unload()) in a try catch after block ... so as long as the cleanup function executes, I think meck:unload() should be always called. Not sure how cover sometimes interacts with all of this in a funny way.

@eproxus
Copy link
Owner

eproxus commented Feb 19, 2021

Sounds like a race condition somehow (asynchronous teardown of a mock at the same time as a set up). Does the error happen if you run individual test cases in isolation?

@SoniCoder
Copy link
Author

have noticed this while running the individual test as well

@eproxus
Copy link
Owner

eproxus commented Feb 20, 2021

Getting this issue when running just one test sounds really weird, especially if you never called meck:new() before. Can you reduce the test to something minimal that I could reproduce?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants