Problem Statement/Rationale

The mongorestore.ParseOptions function uses log.SetVerbosity which mutates the unprotected global log.globalToolLogger. At the same time, mongorestore.MongoRestore.Restore() reads the same unprotected global when using the log package}}

When using multiple restore operations concurrently, as happens when using the package in integration tests (e.g. with dockertest) to load BSON fixtures to test databases, running these tests with t.Parallel() triggers a race detection on these mutations and reads.

A workaround is to wrap from before ParseOptions() to after Restore() in a mutex Lock/Unlock in the code using the package, but it significantly reduces concurrency.

Steps to Reproduce

How could an engineer replicate the issue you’re reporting?

• Set up a tabular test restoring with the mongorestore functions to a different database each time (e.g. dockertest, testcontainers)
• Run the sub-tests in. t.Run(name, func (t *testing.T) with {{t.Parallel}}
• Run the tests with the race detector enabled. You will observe race conditions between
  • the ParseOptions mutations during setup
  • the log.Logvf() calls during restore

Expected Results

What do you expect to happen?

No race condition.

Actual Results

What do you observe is happening?

Race conditions detected by the race detector.

Additional Notes

• Beyond wrapping restores in a mutex lock, which basically defeats most of the parallelism, a better approach would be to wrap the mutations and read uses of the global within the package itself.
• Until this happens, another workaround is to run with GOMAXPROCS=1.