On Tue, Jan 14, 2025 at 12:48 PM David Smiley <dsmi...@apache.org> wrote:
> Any way, for V1, CloudSolrClient sends a parameter like this: > _stateVer_=collection1:3 > It's used for distributed ClusterState cache invalidation by > CloudSolrClient.[1]. It's a list of collections and their versions > (consider that aliases may point to multiple collections). > For V1 HttpSolrCall could consider this parameter in resolving the > ambiguity of the path. It's maybe a hack, depending on your point of view. > It can be used to nicely inform the client that their state is out-of-date (HTTP 510), then the CloudSolrClient client can update its state and route correctly. 510 is maybe better than 404 in this case but 404 works. This works today and is tested: org.apache.solr.client.solrj.impl.CloudSolrClientTest#testRetryUpdatesWhenClusterStateIsStale > If that parameter is supplied, and if the path isn't a collection name > then it can be resolved against the cores of the collection(s) of > stateVer. Ultimately SOLR-17568 (main-only) could be partially reverted > and then modified as I propose in this discussion. > I think I'm wrong about this idea. If a replica moves (they don't truly move BTW) then there will be a new core name on the new node; it won't be found in cluster state. I get replica & core names confused but I think it makes no difference.
