The MembershipTable implementations of Microsoft.Orleans.Clustering.Redis and Microsoft.Orleans.Clustering.AdoNet are inconsistent

[pb0501x]

The MembershipTable implementations of Microsoft.Orleans.Clustering.Redis and Microsoft.Orleans.Clustering.AdoNet are inconsistent because the clusterKey of Microsoft.Orleans.Clustering.Redis contains serviceId, so two keys are stored in the Hash structure of redis. When my client connects to service1's IGrain. Then use service2's IGrain in service1. An exception will occur at this time. The reason for the exception is that the interface cannot be implemented. The solution is to put _clusterKey = Encoding.UTF8.GetBytes($"{_clusterOptions.ServiceId}/members/{_clusterOptions.ClusterId}");=> in the RedisMembershipTable constructor
_clusterKey = Encoding.UTF8.GetBytes($"members/{_clusterOptions.ClusterId}");
In this way, the expected cluster behavior of the two libraries is consistent.

[ReubenBond]

@pb0501x can you confirm that this PR is about ADO.NET & Redis? Or is it about two different Redis providers?

[pb0501x]

What I want to express is that the essential principle of implementing IMembershipTable should be the same between Microsoft.Orleans.Clustering.Redis and Microsoft.Orleans.Clustering.AdoNet. When I tested using ADO.NET, they had the same clusterId, but different serviceId. When starting silo, service1 and service2 can be recognized normally, but when based on redis, they cannot recognize each other and exist independently of each other. I looked at the source code and found that the problem is that the implementation of RedisMembershipTable uses the "serviceId/members/clusterId" combination as the only key, so different serviceIds cannot be combined with the same clusterId to form a cluster.
@ReubenBond