SOLR-18129: Keep multi-valued request-handler defaults on the Config API

[nick-boss-tech]

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

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

What happens today

update-requesthandler via the Config API is broken for multi-valued parameters. When a request handler's defaults, appends, or invariants section repeats a key (the JSON form of a multi-valued parameter), the command parser keeps only the last value and silently drops the rest. A handler configured through the API ends up with a single value where the configuration asked for several, with no error.

What this change does

CommandOperation now parses the request-handler commands with an accumulating object builder, so duplicate keys inside the defaults, appends, and invariants sections accumulate into lists instead of collapsing, and normalizeCommandData keeps those sections multi-valued for the add-requesthandler, update-requesthandler, and create-requesthandler commands. The accumulation is scoped to those commands and those sections; every other command keeps the previous last-value-wins behavior for duplicate keys. The ref guide's config-api page documents the behavior.

Proof

Verified at head 72fd153 on 2026-10-04, with Error Prone enabled. The earlier tests ran on the fork's GitHub Actions test runner; the array-form tests below were verified in a local gate re-run (tidy, Error Prone compile, focused tests, module check). The base-code comparisons ran the same test classes against a tree with base production code and this PR's test files.

• TestUtils: 20 of 20 pass with this change. On base code, the nested duplicate-key cases fail: they expect [subject, country] and get only the last value. The failing cases cover the defaults, appends, and invariants sections.
• TestSolrConfigHandler: 13 of 13 pass with this change. End to end, create is covered for all three sections and update for defaults; appends and invariants updates are covered at the parser level in TestUtils, where all three sections use update-requesthandler. On base code, the end-to-end cases fail the same way: the handler read back through the Config API holds only the last value.

The array-of-commands form (a JSON array of command objects under one command name) is covered at both levels too: a parser-level test in TestUtils and an end-to-end test in TestSolrConfigHandler. Both fail against base production code, where a command sent in that form kept only the last value of a repeated key, and both pass with this change. To isolate the list-form handling itself, both tests were also run against production code from the previous head, 63b1689, where the single-object form already accumulated and only CommandOperation differs: both fail there too (the parser test expects [x, y] and gets only y; the end-to-end test's defaults hold only the last value), and both pass at this head. The single-object accumulation test passes against the previous head as well, and the guard test pinning last-value-wins for other commands in list form passes both ways by design. So the base comparison shows the feature as a whole, and the previous-head comparison isolates the list-form change.

A choice to check

One fact first: sending the values as a JSON array already works today, on base code as well as with this change, and the ref guide text in this PR calls arrays the portable encoding. So no user is without a way to send several values; the question is only what a repeated key should do.

This PR makes the shared Config API parser accumulate duplicate keys, scoped to the request-handler sections above. The cost of that route is about 110 lines of new code in CommandOperation, a solrj class that every command API parses through, with the three command names and the three section names hard-coded in the parser. The other routes were to reject duplicate keys with an error, or to leave the parser strict and document arrays only. I chose accumulating over rejecting because payloads that repeat these keys are silently truncated today; rejecting would make them start failing outright, while accumulating gives them the values the sender plainly listed. If you would rather the parser stay strict, I can reduce this to the documentation route instead.

Limits

Only the three request-handler commands and their defaults/appends/invariants sections accumulate duplicate keys. Nested structures deeper than those sections are not treated specially. A client that relied on last-value-wins inside these sections (for example a templated payload where a later key overrides an earlier one) now gets both values. A repeated section itself, two defaults objects in one command, is not merged; the last one wins. A repeated key whose values mix an array and a scalar is flattened into one list; no test covers that mix. add-initparams and update-initparams accept the same three section names and still drop repeated keys. The v2 Config endpoint parses through the same code and accumulates too; the end-to-end tests post to /config on v1 only. Accumulating duplicate keys for every Config API command would be a broader change; it is not done here, and I can open a ticket for it if you would like it tracked.

Changelog: changelog/unreleased/SOLR-18129.yml (fixed)

AI assistance

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