Repository navigation
SOLR-18606: Refresh missing collection state without repeated alias lookups - #5314
Draft
nick-boss-tech wants to merge 5 commits into
Draft
nick-boss-tech wants to merge 5 commits into
nick-boss-tech wants to merge 5 commits into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🤖 AI text below 🤖 (posted on behalf of Nick Shanin)
Draft status is due to Nick Shanin's open-PR cap; the change is complete and ready for review.
https://issues.apache.org/jira/browse/SOLR-18606
What happens today
A newly created collection can be rejected by a client with a stale ZooKeeper view.
The ZooKeeper cluster-state provider returns no collection state when its local view has not yet learned of the collection. CloudSolrClient can then report "Collection not found" before sending the request.
What this change does
Refresh missing collection state while keeping known aliases off the refresh path.
The ZooKeeper provider checks its local collection and alias views first, then forces a collection refresh on a miss. It propagates ZooKeeper failures and restores the interrupt flag when interrupted. Known alias names avoid the repeated forced lookup that caused SOLR-17275.
Proof
The new tests cover a stale ZooKeeper collection view and the known-alias refresh guard.
Linux verification at 29caa42
On 2026-11-09 with JDK 21 and seed
18606CAFE, all 36 tests passed with no skips:ZkStateReaderTest: 19 tests, including the three new provider tests.AliasIntegrationTest: 9 tests.CloudSolrClientCacheTestandCloudSolrClientRoutingTest: 8 tests.The new collection test failed on the base at the missing-reference assertion. Removing the alias guard caused the alias test to fail because a forced refresh was called.
./gradlew tidyand./gradlew check -x testpassed; the root check used a clean normal clone after Antora rejected the linked worktree's.gitpointer.A choice to check
I recommend refreshing client state on a miss.
Forwarding an unknown collection request to a live node is the other approach discussed on the issue. Refreshing the client view retains normal client routing when ZooKeeper has the collection, at the cost of a ZooKeeper lookup on a miss. Does this choice look right?
Limits
Unknown names can still trigger repeated lookups, and the alias view is not forcibly refreshed.
The real ZooKeeper test checks provider discovery, not an end-to-end client request. The known-alias test counts refresh calls and is not a latency benchmark. A stale alias view and repeated requests for nonexistent names remain outside this change; I can open follow-up issues if useful.
Changelog: SOLR-18606.yml
AI-generated description. Nick Shanin directed the work and takes responsibility for this contribution.