Closed calmh closed 4 months ago
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @MehaKaushik @Pilchie @Wmengmsft.
@simorenoh @ealsur - any ideas?
Interesting. This would indicate that the policy's instance is not tied to the request, but shared, which then means that the retry state:
is wrong. And should be instead part of the request and extracted through req.OperationValue
One alternative is to incorporate the retry counters into pipelineRequestOptions
:
type retryContext struct {
useWriteEndpoint bool
retryCount int
sessionRetryCount int
preferredLocationIndex int
}
type pipelineRequestOptions struct {
....
retryContext retryContext
}
And then use that to track across the client retry policy execution.
@calmh We'll fix this. Working on a PR
We'll release the new package on 6/17
Sorry to bump the issue again, just want to say I'm super impressed with the rapid handling and communication here. Top notch, peeps. 🙏
@calmh Please confirm if your issue is resolved with 1.0.3
Yep, seems fine!
When upgrading from azcosmos 0.3.6 to 1.0.1 we see race detector warnings when concurrently doing
(*ContainerClient).ReadItem()
. We do this in several places for performance/concurrency, and so far it has worked well. Now, however it gives us this:The actual race seems to be on a counter of sorts, I'm not sure if this is new and should be fixed, of if it's intended that it's not supported to make concurrent requests to
ReadItem
? The latter would be a bit of a bummer, we have a lot of requests coming in to the database layer and having to create a client for each of them seems inefficient.