Prevent re-adding deleted sessions to Redis principal index

[seonwooj0810]

Closes gh-1843

Root cause

RedisSession#saveDelta() re-adds the session id to the resolved principal's Redis index set whenever the delta contains the principal/security-context attribute key — this branch does both a removal (of the id from whatever principal it was previously indexed under) and, if a principal still resolves, an unconditional re-add.

RedisIndexedSessionRepository#deleteById() calls cleanupPrincipalIndex(session) to remove the session id from its principal's index set, then sets maxInactiveInterval to Duration.ZERO and calls save(session), which invokes saveDelta().

Under SaveMode.ALWAYS, the RedisSession constructor unconditionally copies every current attribute (including the principal-index attribute) into delta, so saveDelta() always takes the principal-index branch when deleting such a session. Since deleteById() never removes the session's own attributes (it only zeroes the TTL), resolveIndexesFor() still resolves the same principal, and saveDelta() re-adds the id right back into the set that cleanupPrincipalIndex() had just removed it from a few lines earlier. The principal's Redis set (...index:...PRINCIPAL_NAME_INDEX_NAME:<principal>) then keeps growing with ids of sessions that were explicitly invalidated (e.g. on logout), leaking memory indefinitely.

This is the mechanism behind gh-1843's original report (SaveMode.ALWAYS + request.invalidate()) and matches the reporter's own code walkthrough in the issue.

Scope vs. related issues/PRs

This repo has a cluster of principal-index-staleness reports, but they're two distinct mechanisms:

• memory leak when session save model is "always" #1843 / Redis Spring Session - Indexes have a TTL of No Limit #3183 (duplicate) here, plus the closed remove PRINCIPAL_NAME_INDEX_NAME when session is exired but index alr… #2616 and Remove expired session from principal index #2869, and the still-open Clean Redis principal index during expiration cleanup #3798, are about sessions that expire naturally and never get cleaned out of the index because the Redis keyspace expiration event was missed (event redelivery gaps, single-node pub/sub in a cluster, etc.). That's a read-time/lazy-cleanup problem in findByIndexNameAndIndexValue/the expiration-cleanup flow, and is a legitimately different, still-open question — I'm not attempting to resolve it here, and Clean Redis principal index during expiration cleanup #3798 remains orthogonal to this change (it touches the expiration-cleanup flow; this PR touches saveDelta(), called from deleteById()).
• This PR fixes the explicit deletion path: a session id is removed from the index and then immediately put back by the same call, regardless of any missed-event scenario. That's what memory leak when session save model is "always" #1843's original reporter (and Redis Spring Session - Indexes have a TTL of No Limit #3183's duplicate) actually hit.

Change

Guard the re-add in saveDelta() with RedisSession#isExpired(). At the point deleteById() calls save(session), maxInactiveInterval has just been set to Duration.ZERO (not a negative "never expires" value), so isExpired() is already true there — no new field or flag needed. The unconditional removal from the previous principal's set is left untouched, since removing a session id from an index is always correct regardless of expiration state; only the re-add was wrong.

Test evidence

Added deleteWhenSaveModeAlwaysThenPrincipalIndexNotReAdded to RedisIndexedSessionRepositoryTests, which sets SaveMode.ALWAYS, gives the session a principal-index attribute, calls deleteById, and asserts the principal set's remove still happens while add is never invoked. Before this change the test fails with TooManyActualInvocations on add (the id is re-added); after the change it passes.

Verification done

1. No in-flight PR: gh pr list --repo spring-projects/spring-session --search "1843" / --search "3183" returned nothing; the only related open PR is Clean Redis principal index during expiration cleanup #3798, which (per above) addresses a different code path.
2. No active self-claim on memory leak when session save model is "always" #1843 itself (last comment 2021); Redis Spring Session - Indexes have a TTL of No Limit #3183 (the duplicate) has no claim either.
3. Code-focused: touches only RedisIndexedSessionRepository.java (1 line) and its test class.
4. Confirmed the bug is still present on current 3.5.x/main by reading saveDelta() and deleteById() and reproducing it with the new test (fails without the fix, passes with it).
5. No parent epic.
6. Not waiting-for-triage (labeled type: bug + in: redis), so the triage-comment gate doesn't apply.

./gradlew :spring-session-data-redis:test --tests '*RedisIndexedSessionRepositoryTests*' → 57 tests, 0 failures. ./gradlew :spring-session-data-redis:checkFormatMain :spring-session-data-redis:checkFormatTest :spring-session-data-redis:checkstyleMain :spring-session-data-redis:checkstyleTest → all pass. Docker-backed integration tests under src/integration-test were not run (not required for this change, which is a pure unit-testable Redis-key-management fix with no new integration surface).

This PR was prepared with AI assistance (Claude); I reviewed the root-cause analysis and diff myself before opening it.