Add multiple reactive keys exist checker

[AnneMayor]

• You have read the Spring Data contribution guidelines.
• You use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.
• You submit test cases (unit or integration tests) that back your changes.
• You added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).

Resolved #2883

[AnneMayor]

I just changed the command to make better readability according to sonarlint rules.

[AnneMayor]

I created a validation method which is for checking if parameterized all keys exist in redis cache. If one of them does not exist, it returns false.
@kutlueren , please check if this function is what you meant to use.

[kutlueren]

Hey @AnneMayor

Awesome to see that you added the function which carries out what I suggested. It is actually more straight forward than I initially thought, maybe I got confused in the codebase but nice! I shall try it out as soon as it gets merged.

[mp911de]

This implementation calls EXISTS for each key issuing a command for each element in the list.

Redis' EXISTS command accepts multiple arguments and returns how many of the keys exist. Our interface should use the existing functionality instead of putting another layer on top of commands with a worse performance behavior.

The issue we have here is however that exists(Publisher<KeyCommand> keys) and exists(Publisher<List<KeyCommand>> keys) or exists(Publisher<MultiKeyCommand>> keys) erase to the same type and we cannot simply introduce such an override.

I suggest to implement Mono<Long> exists(List<ByteBuffer> keys) directly instead of using default methods. Also, ReactiveRedisOperations should be extended with countExistingKeys(…) similar to RedisTemplate.countExistingKeys(…).

[kutlueren]

Hey @AnneMayor, I just wanted to follow up on the topic :) Is this being planned to be merged soon?

[AnneMayor]

Hey @kutlueren ,
Unfortunately I have no feedback from our maintainer🥲
I am still waiting for their feedback.

[kutlueren]

Hey @kutlueren , Unfortunately I have no feedback from our maintainer🥲 I am still waiting for their feedback.

@mp911de would you mind taking a look at this one when you have time?

[AnneMayor]

@mp911de ,
Please let me know if this PR has some issues🙏

[mp911de]

I did a review pass and left a comment regarding the design and implementation. Care to have a look?

[mp911de]

This implementation calls EXISTS for each key issuing a command for each element in the list.

Redis' EXISTS command accepts multiple arguments and returns how many of the keys exist. Our interface should use the existing functionality instead of putting another layer on top of commands with a worse performance behavior.

The issue we have here is however that exists(Publisher<KeyCommand> keys) and exists(Publisher<List<KeyCommand>> keys) or exists(Publisher<MultiKeyCommand>> keys) erase to the same type and we cannot simply introduce such an override.

I suggest to implement Mono<Long> exists(List<ByteBuffer> keys) directly instead of using default methods. Also, ReactiveRedisOperations should be extended with countExistingKeys(…) similar to RedisTemplate.countExistingKeys(…).

[AnneMayor]

I did a review pass and left a comment regarding the design and implementation. Care to have a look?

Thanks a lot. I am going to apply your review within this weekend 👍

[dreamstar-enterprises]

Any luck solving this?

I have the same issue. Wanting to check the existence of multiple keys using exists in a single network call, without resorting to Lua, but using Springs own implementation

[dreamstar-enterprises]

My current workaround, since the spring API does not support exists with multiple keys yet.

/**
     * Executes expired session cleanup in Redis.
     *
     * Spring Session Redis uses multiple keys per session:
     * 1. Hash key (namespace:sessions:{id}) - Stores session data with 35 min TTL
     * 2. ZSet entry - Tracks session expiration times for batch cleanup
     *
     * Process flow:
     * 1. Query ZSet for sessions that should be expired
     * 2. Access their hash keys to trigger Redis expiration events
     *    - Redis only guarantees expiration events when keys are accessed
     *    - Spring Session listens for these events to cleanup related keys
     * 3. Remove processed entries from the ZSet
     *
     * Implementation details:
     * - Uses Lua script for efficient multi-key EXISTS checks
     * - Handles quoted session IDs in ZSet vs unquoted in hash keys
     * - Relies on Redis keyspace events for actual session deletion
     * - Bounded elastic scheduling for background processing
     *
     * @param context Operation boundaries and limits for ZSet query
     * @return Mono<Void> completing when cleanup process finishes
     * @throws RedisConnectionException if Redis operations fail
     *
     * @see "https://docs.spring.io/spring-session/reference/configuration/reactive-redis-indexed.html#how-spring-session-cleans-up-expired-sessions"
     */
    private fun cleanupExpiredSessions(context: CleanupContext): Mono<Void> =
        redisOperations.opsForZSet()
            .reverseRangeByScore(redisKeyExpirations, context.range, context.limit)
            .collectList()
            .flatMap { sessionIds ->
                if (sessionIds.isEmpty()) {
                    logger.debug("No expired sessions found")
                    Mono.empty()
                } else {
                    logger.debug("Found {} expired sessions to remove", sessionIds.size)

                    // Prepare session keys (remove quotes around session id in zset)
                    val sessionKeys = sessionIds.map { sessionId ->
                        "${sessionProperties.redis?.sessionNamespace}:sessions:${sessionId.trim('"')}"
                    }.also { keys ->
                        logger.debug("Checking Redis keys: {}", keys)
                    }

                    // First read the hash keys to trigger expiration event
                    val script = """
                       local keys = ARGV
                       local count = 0
                       for i, key in ipairs(keys) do
                           count = count + redis.call('EXISTS', key)
                       end
                       return count
                    """

                    redisOperations.execute(
                        RedisScript.of(script, Long::class.java),
                        listOf(),  // KEYS list is empty
                        sessionKeys
                    )
                    .doOnNext { count ->
                        logger.debug("Accessed {} session hash keys", count)
                    }
                    .flatMap { _ ->
                        redisOperations.opsForZSet()
                            .remove(redisKeyExpirations, *sessionIds.toTypedArray())
                            .doOnSuccess { logger.debug("Successfully removed {} expired sessions", sessionIds.size) }
                            .doOnError { e -> logger.error("Error during removal: ${e.message}") }
                    }
                    .then()
                }
            }
            .subscribeOn(Schedulers.boundedElastic())