What causes "Failed to deserialize object" in redis/jedis?

Fix serialVersionUID (declare and keep it stable) or clear/invalidate the cache after deploying class changes.

redis/jedis · error · JedisCacheException

Failed to deserialize object

Error message

Failed to deserialize object

What it means

CacheEntry.toObject deserializes cached bytes with ObjectInputStream; IOException or ClassNotFoundException during readObject is wrapped in JedisCacheException('Failed to deserialize object'). This happens when bytes in the cache cannot be turned back into the value type — typically because the class changed, is missing, or the bytes were written by a different code version.

Solutions

Fix serialVersionUID (declare and keep it stable) or clear/invalidate the cache after deploying class changes.
Ensure the value class is present in the classpath of the reading application (ClassNotFoundException case).
Wrap cache reads with a fallback that treats deserialization failure as a cache miss and reloads from Redis.
Prefer a versioned serialization format (JSON/protobuf via custom Cacheable) over Java serialization to survive schema evolution.

Example fix

// before
class UserDto implements Serializable { String name; } // serialVersionUID auto-computed, changes on edit
// after
class UserDto implements Serializable {
  private static final long serialVersionUID = 1L;
  String name;
}

Defensive patterns

Strategy: fallback

Validate before calling

// verify readability of previously cached entries after a deploy:
// iterate cache entries and attempt cache.get(); treat JedisCacheException as a miss and repopulate

Try / catch

try {
  return cache.get(keyBytes);
} catch (JedisCacheException e) {
  if (e.getMessage().contains("Failed to deserialize")) {
    cache.delete(keyBytes); // stale/incompatible entry
    return loadFromRedis(keyBytes); // fallback source of truth
  }
  throw e;
}

Prevention

Declare and never change serialVersionUID on cached value classes
Flush/clear the cache on rolling deploys that touch cached classes
Keep the value classes on the classpath of every app sharing the cache
Prefer JSON/protobuf via a custom Cacheable for cross-version stability

When it happens

Trigger: Reading a cache value whose stored bytes were serialized with a different serialVersionUID (class evolved between writes); the deserialized class is not on the classpath (ClassNotFoundException); bytes written by another process/app with a different schema; corrupted cache bytes.

Common situations: Rolling deploys where old serialized entries persist in the cache while new code has modified the value class; hot reload / dev restarts reusing a serialized cache; shared cache across services with slightly different class versions.

Understand the failure class

Background: "failed to unmarshal" / json.Unmarshal errors: why parsing a response into a Go struct fails and how to fix it — this error's family across 23 libraries.

Related errors

AI-assisted analysis of redis/jedis@6dac31d4c2 (2026-09-08). Data as JSON: /api/errors/3c45e88b98705774. Report an issue: GitHub.

Appendix: source

Thrown at src/main/java/redis/clients/jedis/csc/CacheEntry.java:53

  private static byte[] toBytes(Object object) {
    try (ByteArrayOutputStream baos = new ByteArrayOutputStream();
        ObjectOutputStream oos = new ObjectOutputStream(baos)) {
      oos.writeObject(object);
      oos.flush();
      oos.close();
      return baos.toByteArray();
    } catch (IOException e) {
      throw new JedisCacheException("Failed to serialize object", e);
    }
  }

  private T toObject(byte[] data) {
    try (ByteArrayInputStream bais = new ByteArrayInputStream(data);
        ObjectInputStream ois = new ObjectInputStream(bais)) {
      return (T) ois.readObject();
    } catch (IOException | ClassNotFoundException e) {
      throw new JedisCacheException("Failed to deserialize object", e);
    }
  }
}

View on GitHub (pinned to 6dac31d4c2)