@episource I've handled the bug you discovered, thanks again.

Is a RWMutex reantrant? The documentation does not say anything about this...

~~Context: ~~
AddInFlight acquires a RW-Lock (mi.inFlight.Lock()) and then calls Has, which tries to acquire a Read-Lock (mi.idxMutex.RLock()). Without RWMutex being reantrant this should fail/dead-lock.

Assuming go locks to be reantrant I tried the same while implementing my draft of StoreInProgress. Due to that I learned the hard way, that my assumption was wrong and Mutex (not RWMutex) is not reantrant.

Edit: Reading my comment again, I noticed that two different lock objects are involved.

Edit: Nothing is locked twice. Everything is alright.

Uhoh. I'll have a look, thanks again!

No, just forget my comment. It's plain wrong.

Hm, I'd expect that acquiring the r lock while an r/w lock is already held leads to a deadlock...

Ah, indeed, now I see it.

Any other comments? Otherwise I'll merge this branch now :)

Not from my side...

cool