[AOT]Generated MongoDB repository query for `...In(String)` produces invalid `$in` (expects array)

[waileong]

Summary

After upgrading to Spring Boot 4 / Spring Data MongoDB 5 (AOT repository code generation), derived query methods using ...In(...) behave differently when the method parameter is a single scalar value (e.g. String).

In non-AOT mode, a single value parameter is accepted (even though it’s not documented) and works like a one-element list.

In AOT mode, the generated code sends $in with a scalar value, and MongoDB rejects it with $in needs an array.

Minimal reproduction project

https://github.com/waileong/spring-data-mongodb-aot-in-query

Versions

• Spring Boot: 4.0.1-SNAPSHOT
• Spring Data MongoDB: 5.0.1
• Java: 25

Steps to reproduce

1. Start MongoDB locally at mongodb://localhost:27017
2. Run the tests:

./gradlew clean nativeTest -i

3. Observe that:
   • ...In(Set/Collection) works
   • ...In(String) fails when using AOT-generated repositories

What I expected

When the repository method is ...In(String value), I expected it to behave like non-AOT mode and treat the value as a one-element list, i.e. generate something equivalent to:

{ "testSet": { "$in": ["A"] } }

(Alternatively, if ...In(String) is considered invalid, it would also be fine to reject it consistently in both AOT and non-AOT modes.)

What actually happens (AOT)

In AOT mode the generated query is equivalent to:

 { "testSet": { "$in": "A" } }

MongoDB rejects it with:

com.mongodb.MongoCommandException: Command execution failed on MongoDB server with error 2 (BadValue): '$in needs an array'

Why this is a problem

Some existing codebases rely on the (undocumented but working) non-AOT behavior where a scalar parameter is accepted for ...In(...).

With Spring Boot 4 / Spring Data MongoDB 5 AOT repository generation, the same repository method signature now fails at runtime, so this becomes an upgrade footgun.

Reference

AOT docs: https://docs.spring.io/spring-data/mongodb/reference/mongodb/aot.html