[
https://issues.apache.org/jira/browse/SOLR-15221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17300566#comment-17300566
]
David Smiley commented on SOLR-15221:
-------------------------------------
Maybe this isn't a problem? In the scenario described, the leader committed
the data successfully since it's the leader that writes locally and does the
distribution. If non-leaders fail, assuming NRT, the worst that could mean
would be stale reads from that non-leader. There used to be a "min_rf"
(minimum replication factor) but it was deprecated and maybe removed –
SOLR-12767. [~tpot] care to comment?
> Distributed commit errors are not propagated to the initiating client
> ----------------------------------------------------------------------
>
> Key: SOLR-15221
> URL: https://issues.apache.org/jira/browse/SOLR-15221
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
> Affects Versions: main (9.0)
> Reporter: Michael Gibney
> Priority: Minor
> Attachments: SOLR-15221-initial-tests.patch
>
>
> Distributed commit errors are not currently propagated back to the client
> that initially issued the commit command. So, any commit (e.g., issued via
> {{CloudSolrClient}}, {{curl}} to Http API, etc.) responds with Http status
> code {{200}}, API status {{0}}, as long as the commit to the "local" core
> arbitrarily associated with the request succeeds. This happens no matter how
> many distributed commits succeed or fail (at least, to other leader replicas
> -- I've only tested w/ replication factor 1 at the moment).
> Inconsistency -- i.e. an error on an arbitrarily-determined "local" replica
> propagates propagates to the client, but an error on all other replicas does
> not -- is the focus of this issue; but this issue is raised with no
> preconceived notions wrt _how_ the inconsistency should be resolved.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
