Ned Batchelder

It turns out this is not a race condition in the creation of the databases. It's a race condition caused by pytest-cov, which is both erasing the data and starting...

@ionelmc /cc about the race condition in pytest-cov. I can elaborate.

One option is to not use pytest-cov, though it means you have to manage the subprocess measurement yourself: https://coverage.readthedocs.io/en/6.2/subprocess.html

This is now fixed in commit b41be3f9

This is now released as part of [coverage 6.3](https://pypi.org/project/coverage/6.3).

*Original comment by* **David MacIver (Bitbucket: [david_maciver_](https://bitbucket.org/david_maciver_), GitHub: Unknown)** ---------------------------------------- For added confusingness, AFAICT the second but not the first of these two lines cannot be pragma-ed away! Adding a...

*Original comment by* **Geoff Bache (Bitbucket: [geoffbache](https://bitbucket.org/geoffbache), GitHub: Unknown)** ---------------------------------------- Implementing a solution like this now appears to be difficult, as the "coverage" object is not necessarily stored in a...

*Original comment by* **Geoff Bache (Bitbucket: [geoffbache](https://bitbucket.org/geoffbache), GitHub: Unknown)** ---------------------------------------- Looking at this again. There are other circumstances where no coverage information is produced because the atexit handlers are not...

For anyone looking for Geoff's changes: ``` diff -r [f7d26908601c (bb)](https://bitbucket.org/ned/coveragepy/commits/f7d26908601c) -r [f3a76cf7aa00 (bb)](https://bitbucket.org/ned/coveragepy/commits/f3a76cf7aa00) coverage/control.py --- a/coverage/control.py Sun Nov 07 19:45:54 2010 -0500 +++ b/coverage/control.py Mon Nov 15 21:36:31 2010...

Considering this for the next release.