stillalex commented on code in PR #1504: URL: https://github.com/apache/solr/pull/1504#discussion_r1162791455
########## solr/core/src/java/org/apache/solr/update/processor/DistributedUpdateProcessor.java: ########## @@ -331,7 +342,7 @@ protected boolean versionAdd(AddUpdateCommand cmd) throws IOException { boolean isReplayOrPeersync = (cmd.getFlags() & (UpdateCommand.REPLAY | UpdateCommand.PEER_SYNC)) != 0; - boolean leaderLogic = isLeader && !isReplayOrPeersync; + boolean leaderLogic = leaderLogicWithVersionIntegrityCheck(isReplayOrPeersync, versionOnUpdate); Review Comment: > f there is some race condition causing the client to route to us (a new sub-shard) before we know that we are ready to accept it, I'd rather not pretend we are ready in any way. this is what I am struggling with. I'm not convinced this can be called a race condition on the client side. the test currently picks an http client and issues a request. this can land on a recovering shard split. I am ok with only having the exception in place (no subShardLeader funny business), but then the test's request will fail, who needs to be responsible for the retry? > Maybe throw an exception like INVALID_STATE that should cause CloudSolrClient to retry I agree with this idea, but I think it also hints at replacing existing test clients with CloudSolrClient, the existing HttpSolrClient does not perform retries. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org