[epugh]

https://issues.apache.org/jira/browse/SOLR-18553

Surveyed v2 (JAX-RS) APIs for query/path/body param names with underscores. Found one genuine, unjustified inconsistency: ListCollectionsApi's GET /api/collections?detailed=true accepted _route_ as a query param, left over from mirroring the v1 wire format even though this specific param has no v1 equivalent to stay compatible with.

Other v2 API response fields with underscores (node_name, base_url, force_set_state, recovery_failed, solr_home, core_root, environment_label, environment_color) were checked individually and are intentional — they mirror either literal ZooKeeper state.json property names (Replica.java's NODE_NAME/BASE_URL/FORCE_SET_STATE` constants) or pre-existing v1 wire formats that predate their JAX-RS migration, so those are out of scope here.

This rename is v2-only:

• v1 LIST calls ListCollections.listCollections(null, null, null, null, null) — the route param is always null, never passed through.
• v1 CLUSTERSTATUS is a fully separate implementation (new ClusterStatus(zkStateReader, req.getParams())) that never goes through ListCollectionsApi.

Also updates the two ref guide spots that documented the old _route_ name for this endpoint.

Test plan

• :solr:api:compileJava / :solr:core:compileJava / :solr:core:compileTestJava all clean
• ListCollectionsDetailedTest (7/7), ListCollectionsDetailedStandaloneTest (1/1) pass
• Confirmed no existing test exercises the old _route_ param name for this endpoint

🤖 Generated with Claude Code

https://claude.ai/code/session_018RwsEje8u9apx3SRzissZm

[github-actions]

Automated PR readiness judgements (LLM-generated; may be wrong; not updated on later pushes).

• ✅ Jira issue in title: already present
• ⚠️ Changelog — missing (suggest type: changed): The PR renames the query parameter `_route_` to `route` on the V2 `GET /​api/​collections?detailed=true` endpoint, which is a user-visible change to an existing API's behavior.​
• ✅ Reference Guide update: included
• ✅ Upgrade notes: included
• ⚠️ Tests — missing: The change modifies the JAX-RS `@​QueryParam` annotation in `ListCollectionsApi.​java`, which is production logic affecting API request parsing, and the description confirms that existing tests were run to verify the change.​

[nick-boss-tech]

Hi Eric,
I added an HTTP test for the route parameter using a collection with two shards. It checks the unfiltered result and both route values. The diff is based on this PR’s current head.

To take the commit:

git switch SOLR-18553-fix-param-naming
git fetch https://github.com/nick-boss-tech/solr.git pr-5319-route-filter-tests
git merge --ff-only d1a47bb29cdd9f69c1b65e813fc2bf13dbb00056

On Linux, ListCollectionsDetailedTest passed 8/8, and tidy passed.

AI-generated.

[dsmiley]

This parameter is named this way for consistency with the /select to target the right shards. There's probably a constant for this param. Unless V2 has a different approach for that, it should be named the same.

[epugh]

This parameter is named this way for consistency with the /select to target the right shards. There's probably a constant for this param. Unless V2 has a different approach for that, it should be named the same.

Humm... in other places in v2 we renamed _route_ to route... Is the prefix/postfix of _ a pattern we use in Solr widely that is important to know? Feels like a "The good idea fairy flew by and dropped off a unique pattern" to me 🤷. I definitly WANT consistency. I suspect that if we had a V2 /select then it would ALSO change it to route instead of _route_.

[dsmiley]

in other places in v2 we renamed route to route

Oh? Can you provide link(s)

I'm not attached to the underscores; I just want to ensure you are aware that this isn't a quirk specific to this handler.