I am not sure if this is appropriate, for this single variable to be used in two goroutine, should we use variables from the atomic package(like atomic.StoreInt32) or use read-write locks. I understand that this way of using locks will be heavier (i.e.: more burdensome?)

I am not sure whether protecting concurrent access (no matter how it is done) fixes the underlying problem. The return below seems to assume that the goroutine which writes wasCreated has terminated. Is that a valid assumption?

If yes, then there has to be some kind of synchronization. The race detector should recognize that synchronization and not report the race. If there is synchronization and the race detector does not detect it, then we have a false positive - that would be very unusual, it heavily errs towards "no false negatives".

If no, then there is a logic error in the flow, which needs to be fixed. Otherwise the return statement could be reached before the goroutine has written the variable, which then passed on the wrong value.

Yeah, looking at the race detector logs, It looks like we had a write after read, so to me that means the synchronization [to wait for the writer to be complete] is broken?

I will try to fix this issue after KubeCon Hong Kong (6/10-6/11) 😄

After looking at the source code, if I understand correctly 🤔 :

The main goroutine waits for the background goroutine to finish via a buffered channel (resultCh) before proceeding.

This ensures that any writes to wasCreated (done inside the background goroutine) are completed before the main goroutine reads it using atomic.LoadInt32.

Therefore, the value of wasCreated is always correct when read.

There is one condition where the goroutine writing the value hasn't completed yet: in case of a canceled context.

In that case, this read here races against the still-running goroutine:

The fix would be to skip that read in case of an error:

// In case of a timeout error, the goroutine handling the request is still running.
// https://github.com/kubernetes/kubernetes/blob/d2c12afa4593e50a187075157d38748292b02733/staging/src/k8s.io/apiserver/pkg/endpoints/handlers/finisher/finisher.go#L127-L146
//
// We cannot reliably read  the variable (data race!) and have to assume that
// the object was not created.
if errors.IsTimeoutError(err) {
    return result, false, err
}
return result, wasCreated, err

Ok, I added the check for errors.IsTimeout(err). 🤔 In addition, I understand that we should also use atomic.LoadInt32? Otherwise, we will still have data race error detection?

We shouldn't need the atomic. Either the goroutine has completed for sure or we don't read the value. In both cases there's no data race.

We shouldn't need the atomic. Either the goroutine has completed for sure or we don't read the value. In both cases there's no data race.

ok, I removed.

Add test cases for this part of the changes. 🤔