Is that race is real for a real client? Because I think it's pretty the same as copy and even slightly worse, because not preallocating anything :(

@LK4D4 I'm not sure there's really a race in the driver as opposed to the test, but this does avoid a (potentially large) copy. To answer your question on #22971, PutLogEvents is indeed a blocking call.

Preallocation can be changed, but what I have now is fairly similar behavior to the truncation that was already occurring.

If it's blocking then let's make mockClient blocking and avoid allocations at all :)

@LK4D4 Making mockClient block doesn't seem to make the race detector happy by itself. I'm not sure exactly what the race detector is unhappy about; the slice element contents are never modified concurrently and the PutLogEventsInput struct gets an independent copy of the slice header. The only modification of the slice itself happens with sort.Sort, but nothing is concurrently modifying the slice during that operation.

@samuelkarp could you post race detector output pls?
And patch for blocking mockClient

samuelkarp@21a5189 shows the mockClient with zero-length channels so that it blocks. Race detector output is here.

Ok, mockClient code is confusing, but as I understand issue we need to make copy of events inside func (m *mockcwlogsclient) PutLogEvents( or test itself will mess with events after this call returns (it returns because we're sending result in channel at the beginning)

@LK4D4 That seems to work too. I'll update this PR with that change.

(Also, if Docker has picked a mock generation tool, I'd be happy to switch away from this confusing, hand-written mock.)

@LK4D4 PTAL

LGTM