[jira] [Commented] (SOLR-15221) Distributed commit errors are not propagated to the initiating client

["David Smiley (Jira)" <ji...@apache.org>]

    [ 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)