Failed rename for deleted session is not ignored with Redisson

[eager]

This is same underlying issue as #1270, with a small twist—the exception message has more detail.

Describe the bug
We’re using RedissonConnectionFactory with our RedisOperationsSessionRepository (we’re still on Spring Session 2.1.13). Redisson’s exception handling adds a little extra context to the exception message, so this check in handleErrNoSuchKeyError fails:

if (!"ERR no such key".equals(NestedExceptionUtils.getMostSpecificCause(ex).getMessage())) {
	// NestedExceptionUtils.getMostSpecificCause(ex).getMessage() →
	//   "ERR no such key. channel: [id: 0xec125091, L:/100.96.17.194:46330 - R:redis/100.67.2.163:6379] command: (RENAME), params: [[115, 112, 114, 105, 110, 103, 58, 115, 101, 115, ...], [115, 112, 114, 105, 110, 103, 58, 115, 101, 115, ...]]"

	throw ex;
}

and the exception bubbles up.

To Reproduce
Make concurrent requests with the same session ID, which both result in changing the session ID—typically via session fixation prevention.

Expected behavior
The session repository gracefully handle concurrent requests that change the session ID.

[Blockost]

Hi @eager ! We just encountered this same issue on our production environment. Were you able to find a workaround ? I wonder if it's safe to catch (and discard) it on our end until this is handled properly by spring-session.

[eager]

@Blockost unfortunately, it's been a couple of years since I worked on the project that hit this issue, but I don't think we had a good workaround.

[Blockost]

Thanks @eager for you answer, we'll try to handle this on our end.

[marcusdacoregio]

Hi folks, I think we should consider providing some strategy to handle the scenario where a concurrent modification might happen.

However, I am not discarding changing the condition to use startsWith instead of equals. Is anyone else aware if there is another Redis client that might change the exception message?