Skip to content

Convert elements of collection- and array-valued query method parameters#3506

Open
seonwooj0810 wants to merge 1 commit into
spring-projects:mainfrom
seonwooj0810:fix/gh-3502-collection-enum-param-conversion
Open

Convert elements of collection- and array-valued query method parameters#3506
seonwooj0810 wants to merge 1 commit into
spring-projects:mainfrom
seonwooj0810:fix/gh-3502-collection-enum-param-conversion

Conversation

@seonwooj0810

Copy link
Copy Markdown

Fixes #3502

Root cause
ReflectionRepositoryInvoker#prepareParameters skipped conversion whenever the resolved value already was an instance of the declared parameter type. For a collection- or array-valued parameter this is wrong: a repeated query parameter (e.g. ?colors=RED&colors=GREEN) resolves to a List<String>, which is an instance of the target List/Collection, so convert(...) was never called and the raw String elements were never converted to the declared element type (e.g. an enum). The unconverted List<String> then reached the in-style query and the persistence provider failed. (As diagnosed by @antonioT90 in the issue, with a reproducer.)

Change
For array- and Iterable-typed parameters, conversion is now performed even when the value already matches the target type, so the elements are converted to the declared element type. Scalar parameters keep the previous fast-path (no redundant conversion).

Tests
Added ReflectionRepositoryInvokerUnitTests#convertsElementsOfCollectionValuedQueryParameter, which binds a List<String> to a Collection<Color> query parameter and asserts the repository receives converted enum values. It fails before the change (repository receives the raw Strings) and passes after.

Verification done: (1) no in-flight PR — searched open PRs for 3502 and ReflectionRepositoryInvoker (only unrelated #3439); (2) no self-claim comments; assignee odrotbohm is routine triage tracking (89 open issues assigned); (3) code-focused, touches only .java; (4) confirmed the pattern still present on current main; (6) issue is past triage (type: bug), so no triage gate. Ran ./mvnw -o test -Dtest=ReflectionRepositoryInvokerUnitTests — 20/20 pass with the fix; the new test fails without it.

…ers.

Query method parameters exposed through Spring Data REST were passed to the
backing repository without element conversion when the raw value already was
an instance of the declared target type (e.g. a `List`). As a result, a
repeated request parameter such as `?colors=RED&colors=GREEN` reached an
`in`-style query as a `List<String>` instead of a `List<Color>`, causing the
persistence provider to fail.

`ReflectionRepositoryInvoker` now also invokes conversion for array- and
`Iterable`-typed parameters even when the value already matches the target
type, so the raw elements get converted to the declared element type.
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Jul 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

status: waiting-for-triage An issue we've not yet triaged

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Query exposed through Spring-Data-Rest will throw an exception if configured a filter on a List of enums

2 participants