89799969 opened a new issue, #4048:
URL: https://github.com/apache/rocketmq-dashboard/issues/4048
### Describe the bug
The paged data-source inventory builds its Spring cache key by concatenating
nullable filter values:
```java
"'page:' + #search + ':' + #type + ':' + #page + ':' + #pageSize"
```
SpEL string concatenation renders a Java `null` as the literal text `null`.
Therefore these distinct requests share the same cache key:
- no search filter: `search == null`
- a real search for the text `null`: `search.equals("null")`
After the unfiltered request is cached, the literal search can receive the
unfiltered page without invoking the repository. Delimiter-containing values
can create similar tuple collisions.
### Steps to reproduce
1. Enable the application's Spring cache configuration.
2. Stub `findDataSources(null, null, 1, 20)` and `findDataSources("null",
null, 1, 20)` with different pages.
3. Call the two service methods in that order.
4. The second call returns the first page and the second repository stub is
never invoked.
I reproduced this on current `rocketmq-studio` (`36126024`) with a focused
Spring caching test; it fails before any production change.
### Expected behavior
Every distinct `(search, type, page, pageSize)` tuple has a distinct cache
entry, including `null` versus literal text.
### Proposed fix
Use Spring's default multi-argument `SimpleKey` for the paged method instead
of serializing arguments into a delimiter-based string, and add the failing
regression test.
I'd like to work on this focused fix.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
