.NET v3.2.x SDK - Usage of `GetAnyReplicaAsync`

[eugene-shcherbo]

Hello,

We’re upgrading to the 3.2.x SDK and encountered an issue with the GetAnyReplicaAsync method (I didn’t check GetAllReplicaAsync).

So this throws ArgumentNullExceptionevery time it’s called after auto-failover event. This is the stack trace:

\nStackTrace:\nInner Exception:\n\nValue cannot be null. (Parameter ‘endPoint’)\nType: System.ArgumentNullException\nSource: Couchbase.NetClient\nTargetSite: Void ThrowArgumentNullException(System.String)\nStackTrace:\n at Couchbase.Utils.ThrowHelper.ThrowArgumentNullException(String paramName)\n at Couchbase.CouchbaseBucket.SendAsync(IOperation op, CancellationTokenPair tokenPair)\n at Couchbase.Core.Retry.RetryOrchestrator.RetryAsync(BucketBase bucket, IOperation operation, CancellationTokenPair tokenPair)\n at Couchbase.KeyValue.CouchbaseCollection.GetReplica(String id, Int16 index, IRequestSpan span, CancellationToken cancellationToken, ITranscoderOverrideOptions options)\n at Couchbase.KeyValue.CouchbaseCollection.GetAnyReplicaAsync(String id, GetAnyReplicaOptions options)\n

Note this doesn’t occur before auto-failover, only after this. I think this is very similar to the related issue in the v2.7.x SDK .net 2.7.X NullReferenceException encountered on GetDocumentFromReplicaAsync<T>

We also didn’t find anything related to the querying replica in the documentation, so could someone please take a look at my following questions and give some advice?

1. Does it even make sense to query replica after auto-failover event? After this event one of the replica node becomes a main node and seems like GetAsync method which queries main nodes should always succeed.

Now we query replica even when a document is not found on a main node.

2. Does this behavior make sense or if a document is not found on the main node, this also 100% won’t be on a replica node?

[jmorris]

@eugene-shcherbo

Looks like you stumbled upon a bug. I created a ticket for tracking: Loading...

Even though this looks a lot like the 2.7.X bug, from the stacktrace I believe its a separate issue.

Replica reads make sense if there is concern that the document will not be found in the primary node for some reason. The SDK will then try to locate the document replica on any of the other nodes in the cluster.

[eugene-shcherbo]

@jmorris ,

Thank you for such a quick reply.

Thinking about situations when a primary node might be behind of a replica. Probably after auto-failover a new primary node (which was a replica before) can be behind of other replicas…

By the way, do you probably know of some workarounds for this bug? We tried to reconnect to the cluster, but this doesn’t help and I think this is expected, because the state of the cluster isn’t changed.