@NivekNK I still don't understand why do we need this specific post-retry exception handling. Since, READONLY error is wrapped into ServerException and handling of this exception enables slot map update.

Please provide a unit test case that shows the behaviour if READONLY error wrapped into ServerException is thrown. I want to understand if internally we do retry and update topology and if we do, why do we need another topology update after all retries happened

@vladvildanov Hi! I've added the unit test you requested to demonstrate the exact behavior when a READONLY error is wrapped inside a ServerException.

As the new test shows, when ServerException is thrown, Predis does catch it and triggers the retry mechanism. However, it does not trigger a topology update (askSlotMap() and disconnect() are never called) because onFailCallback() only evaluates and handles connection-level errors (ConnectionException). As a result, the automated retry loops infinitely against the very same broken node until it hits the retry limit, ultimately bubbling up the exception to the end user.

This is exactly why my explicit handling in onErrorResponse and onReadOnlyResponse is strictly necessary to cleanly survive AWS ElastiCache OSS failover events. By manually catching the -READONLY keyword inside ErrorResponse and explicitly triggering askSlotMap() + disconnect(), we actively force the topology to refresh and successfully re-route the failed command to the newly promoted primary node.

Let me know what you think and if you need any further adjustments.

I see the CI failed on testClusterExecutePipeline throwing a MOVED ServerException. Since my code exclusively touches the READONLY case in onErrorResponse(), it is unrelated to this flaky pipeline test failure. Could you please re-run the CI jobs?

@NivekNK Thanks for the detailed explanation, no more objections from my side!