[automatic failover] Adding failover tests for all unhealthy#4449
[automatic failover] Adding failover tests for all unhealthy#4449atakavci wants to merge 2 commits into
Conversation
| } | ||
|
|
||
| @Test | ||
| public void recoveryAfterPermanentException_withFailbackDisabled() { |
There was a problem hiding this comment.
TBH, don't like such tests, and will go without it
.failbackSupported(false), but then we wait 1s to ensure no failback, which is non-deterministic
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| // The system knows there's a healthy database available (db1), but the active database | ||
| // is still the disabled one (db0), so commands will fail with JedisConnectionException | ||
| // (not JedisPermanentlyNotAvailableException, because canIterateFrom returns true now) | ||
| assertThrows(JedisConnectionException.class, () -> jedis.get("test-key")); |
There was a problem hiding this comment.
Weak assertion doesn't verify exact exception type
Medium Severity
The assertThrows(JedisConnectionException.class, ...) at this line doesn't verify the exception is specifically JedisConnectionException and not JedisPermanentlyNotAvailableException, since the latter is a subclass of the former. The comment on lines 429-432 explicitly states the exception is expected to be JedisConnectionException (not JedisPermanentlyNotAvailableException), but the assertion would pass for either. Existing tests in this file (lines 293-294, 296-297) follow the pattern of using assertEquals(JedisConnectionException.class, e.getClass()) to verify the exact type. Without that check, this test cannot detect a regression where the permanent failure state isn't properly reset after re-enabling a database.
2 participants
Adding tests for recovery cases that all endpoints gets unhealthy
Note
Low Risk
Test-only changes; main risk is increased integration test flakiness due to timing/awaitility-based assertions.
Overview
Adds two new integration tests in
MultiDbConnectionProviderTestcovering recovery after the provider entersJedisPermanentlyNotAvailableExceptionwhen all databases become disabled/unhealthy.The new cases assert (1) with
failbackSupported(true)the client automatically fails back to the higher-weight database once it is re-enabled, and (2) withfailbackSupported(false)recovery requires manual intervention (setActiveDatabase) even after a database is made healthy again.Written by Cursor Bugbot for commit d2c02d4. This will update automatically on new commits. Configure here.