fix(logger): Make MockLogger threadsafe #441
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When using a
logger.MockLogger()
, a background goroutine callinglogger.Noticef()
might race the underlyingbytes.Buffer
for read/write access. To avoid that, limit the returned buffer type forMockLogger()
to justfmt.Stringer
(and mutex-protect its reading from the buffer) as well as mutex-protectWrite()
calls to the underlying buffer.To reproduce the race condition, run
go test -race ./internals/logger
withTestMockLoggerReadWriteThreadsafe
added, but with the unmodifiedMockLogger
implementation.If more functions from
bytes.Buffer
are needed from theMockLogger
return value, the interface can be expanded with additional pass-through lock-protected calls, but in all of Pebble, it seems only the.String()
function is used, so only that is exposed for now.While
logger.Noticef()
calls are serialized bylogger.loggerLock
, the same cannot be said for parallel access to the underlyingbytes.Buffer
that is returned fromMockLogger
when callinglogger.Noticef()
in one goroutine, and accessing thebytes.Buffer
from another goroutine.