SOLR-12849: keep a POST body's collection parameter when the path names multiple collections

[nick-boss-tech]

🤖 AI text below 🤖 (posted on behalf of Nick Shanin)

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

What happens today

The list of collections HttpSolrCall works with is computed from the URL parameters. A collection parameter that arrives only in the form body of a POST is not part of that list. When the URL path names two or more collections, for example a two-collection alias, and the POST body carries its own collection parameter, addCollectionParamIfNeeded silently replaces the body value with the joined path list: the parameter the client sent is overwritten inside the request. In the tests run for this PR (see Proof), no wrong end-to-end result was observed on the base code; the demonstrated defect is this overwrite itself.

What this change does

addCollectionParamIfNeeded now detects a collection parameter that is present in the merged request parameters but absent from the URL parameters, resolves its aliases with resolveCollectionListOrAlias, and uses the resolved list. A body-only value is therefore kept, with its aliases resolved, instead of being replaced by the path list. Requests that carry the parameter in the URL behave exactly as before.

Proof

Verified at head cd7bd79 on 2026-10-04: tidy, compile with Error Prone enabled, the focused tests below, and :solr:core:check -x test all pass.

• HttpSolrCallCollectionParamTest: 1 of 1 passes. This is the discriminating test: it calls addCollectionParamIfNeeded directly with a two-collection path and a collection parameter in the body only. Against base production code it fails, because the method replaces the body value with the joined path list (expected the body value, got emptycollection,doccollection). That base comparison ran on the fork's GitHub Actions test runner, against a tree with base production code and this PR's test files. With this change the body value is kept.
• AliasPostBodyTest: 4 of 4 pass. The same tests also pass against base production code (local run on 2026-10-04: 4 tests, 0 failures, in a tree with base production code and this PR's AliasPostBodyTest only). They pass on base because the SolrJ client used in the test moves the collection parameter into the URL query string (it is part of the client's default urlParamNames set), and a URL collection parameter already takes precedence over the path in HttpSolrCall and has its aliases resolved there, so these requests never present a body-only parameter to the server. The end-to-end cases pin the end behavior but do not discriminate; the method-level test above is the one that fails on base.

Limits

The discriminating evidence is a method-level test; the end-to-end cases pass on base code as well, for the reason given under Proof. A body-only collection parameter arrives from clients that do not promote it to the URL, for example a plain HTTP form post, and no end-to-end test covers that client shape.

The v2 API path (V2HttpCall) calls the same method, but the overwrite cannot arise there as a multi-collection case: v2 rejects a request whose path or URL collection parameter resolves to more than one collection with a 400 before the method runs, and its core-based paths pass the method an empty list. The alias-resolution half of this change does run on the v2 path: a single-collection v2 request whose body collection parameter names an alias now has that alias resolved. No test posts to a v2 path.

On the v1 path, the overwrite is reached only when the receiving node hosts a replica of the path's first collection; when it does not, the request is proxied to another node before the method runs.

Changelog: changelog/unreleased/SOLR-12849.yml

AI assistance

AI agents assisted with research, implementation, review, and drafting. Nick Shanin directed the work and takes responsibility for this contribution.