[
https://issues.apache.org/jira/browse/SOLR-18154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18133863#comment-18133863
]
David Smiley commented on SOLR-18154:
-------------------------------------
For the case of a single CloudSolrClient creating the collection and then doing
something with it, I think we'll want the "stateVer" tracking to help make sure
a partial/incomplete state isn't used. The return header for creation should
have the final stateVer. If the client sees it's cache state is out of date,
it should remove it's entry. The subsequent request must first get the latest
state, and also furthermore pass that state version on with the next request so
that whatever Solr node receives it is also looking at a state that is at least
that far up to date. In saying all this, I'm _not_ saying each of these is a
current gap nor am I saying it works perfectly. That's TBD. SOLR-17601 is
partly related.
> SolrCloud: collection creation should be synchronous (no waitForState needed)
> -----------------------------------------------------------------------------
>
> Key: SOLR-18154
> URL: https://issues.apache.org/jira/browse/SOLR-18154
> Project: Solr
> Issue Type: Improvement
> Components: Tests
> Reporter: David Smiley
> Priority: Major
>
> 🤖 Goal: when a CREATE collection request returns successfully, the collection
> is fully usable. Any client (CloudSolrClient included) can immediately index
> and query it, without polling via {{waitForState}} /
> {{waitForActiveCollection}}. Our SolrCloud tests nearly always call these
> after creating a collection, which hides real issues. Users shouldn't need to
> do this either.
> This is an umbrella. Linked "Required" issues must be done before we can
> safely remove these calls from tests. Expect more to be discovered as test
> calls are removed.
> h3. Plan
> * On *main only*, remove the post-creation waits from the tests in a primary
> package first (e.g. the core {{cloud}} test package), then watch it for flaky
> failures. Each new failure pattern becomes a linked issue here.
> * Once that package has been stable for a while, do a final pass removing the
> remaining calls everywhere else.
> * Do not backport the test changes until main has been stable for a while.
> h3. Known concerns
> * CREATE may return before replicas are active (SOLR-17712,
> {{waitForFinalState}} defaults to false).
> * A client with a stale view may not know the collection exists (SOLR-18606).
> * A client may see a collection that is still being built, e.g. replicas not
> yet active or no leader yet. Unknown whether stale-state retry handles this
> cleanly. File an issue if tests show it.
> Out of scope initially: other replica-creating commands (ADDREPLICA,
> SPLITSHARD, RESTORE), which have similar issues.
> 🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
