Thanks for reporting this, I have taken a look.

First, although the test you provided demonstrated the problem in upsidedown, I suspected it may affect both upsidedown and scorch (or at least we should test both to see). I adapted your test to run one level higher, at the top-level bleve package.
The results were a bit surprising, because we already encountered a similar bug in the past (Data race in Batch.Reset() #260). And further, we added a test for that then, and that test is passing with the race detector (for both upsidedown and scorch).
So what is different about your test? Notably, you're indexing empty batches. In fact, if you add a line to your test to index a document each time, you'll notice that the race detector passes. So, there was something special about the case of indexing empty batches, and reusing the batch that was triggering the race detector.

What I've determined is that when there documents in the batch, we internally synchronize things by going over a channel, thus the race detector can prove that the access is safe. However, when there are no documents in the batch, the loop iteration happens 0 times, and we never go through that channel synchronization, and thus the race detector correctly points out this bug.

It turns out the fix is straightforward, we can eliminate the unsynchronized access by the other goroutine in the case when there are no documents, thus removing the race.

I'll be submitting a PR to address this issue shortly.

Potential data race #1092

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions