[jira] [Created] (SOLR-16437) ClusterStateUpdater suppresses errors found while processing queue items

["Jason Gerlowski (Jira)" <ji...@apache.org>]

Jason Gerlowski created SOLR-16437:
--------------------------------------

             Summary: ClusterStateUpdater suppresses errors found while processing queue items
                 Key: SOLR-16437
                 URL: https://issues.apache.org/jira/browse/SOLR-16437
             Project: Solr
          Issue Type: Bug
      Security Level: Public (Default Security Level. Issues are Public)
    Affects Versions: main (10.0)
            Reporter: Jason Gerlowski


I was playing with the ADDREPLICAPROP API recently, and noticed that Solr returns a 200 even when I accidentally misspelled the replica name.  Steps to reproduce:

{code}
git checkout main
./gradlew clean assemble
cd solr/packaging/build/solr-10.0.0-SNAPSHOT
bin/solr start -c
bin/solr create -c foo
curl -ilk -X GET "http://localhost:8983/solr/admin/collections?action=ADDREPLICAPROP&collection=foo&shard=shard1&replica=invalidReplicaName&property=someProp&property.value=someVal"
{code}

It looks like Solr *does* notice the invalid replica name, and the following appears in the logs:

{code}
ERROR (OverseerStateUpdate-72202151666515968-localhost:8983_solr-n_0000000000) [] o.a.s.c.Overseer Overseer could not process the current clusterstate state update message, skipping the message: {
  "replica":"invalidReplicaName",
  "property.value":"someVal",
  "property":"someProp",
  "collection":"foo",
  "shard":"shard1",
  "operation":"addreplicaprop"} => org.apache.solr.common.SolrException: Could not find collection/slice/replica foo/shard1/core_ndoe2 no action taken.
        at org.apache.solr.cloud.overseer.ReplicaMutator.addReplicaProperty(ReplicaMutator.java:163)
org.apache.solr.common.SolrException: Could not find collection/slice/replica foo/shard1/core_ndoe2 no action taken.
        at org.apache.solr.cloud.overseer.ReplicaMutator.addReplicaProperty(ReplicaMutator.java:163) ~[?:?]
        at org.apache.solr.cloud.Overseer$ClusterStateUpdater.processMessage(Overseer.java:527) ~[?:?]
        at org.apache.solr.cloud.Overseer$ClusterStateUpdater.processQueueItem(Overseer.java:430) ~[?:?]
        at org.apache.solr.cloud.Overseer$ClusterStateUpdater.run(Overseer.java:357) ~[?:?]
        at java.lang.Thread.run(Thread.java:829) ~[?:?]
{code}

...but the problem is never surfaced to the user, presumably because there's no synchronous validation of the inputs before they're used to create a message for the overseer/state-updater.

Maybe we should update this (and other APIs) to do a best-effort sanity-check of input parameters before shipping them off to the asynchronous work queue.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org