[
https://issues.apache.org/jira/browse/SOLR-15221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17300614#comment-17300614
]
Ilan Ginzburg commented on SOLR-15221:
--------------------------------------
If we decide it is not a problem, then for consistency a failed commit on the
"local" node should not return an error. One would be entitled to then question
the value (meaning) of a commit.
> 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)
