redis/jedis · error · JedisValidationException

DriverInfo must not be null

Error message

DriverInfo must not be null

What it means

DriverInfo.builder(DriverInfo) requires an existing DriverInfo instance to copy values from. Passing null cannot produce a meaningful builder, so Jedis throws JedisValidationException('DriverInfo must not be null') eagerly. This is a fail-fast guard on a programming error rather than a runtime condition.

Solutions

  1. Ensure the DriverInfo passed to builder() is initialized before the call.
  2. For a fresh instance, call the no-argument DriverInfo.builder() overload instead of builder(null).
  3. If the value can legitimately be absent, branch: use the no-arg builder when null, the copying builder otherwise.
  4. Guard the calling code with Objects.requireNonNull and a clear message to surface the miswired source earlier.
  5. Check the code path that supplies the DriverInfo (config/session getter) for logic returning null.

Example fix

// before
DriverInfo.Builder b = DriverInfo.builder(session.getDriverInfo()); // may be null

// after
DriverInfo existing = session.getDriverInfo();
DriverInfo.Builder b = (existing != null)
    ? DriverInfo.builder(existing)
    : DriverInfo.builder();
Defensive patterns

Strategy: type-guard

Validate before calling

if (driverInfo == null) {
  driverInfo = DriverInfo.builder().build(); // or use the no-arg builder
}
DriverInfo.Builder b = DriverInfo.builder(driverInfo);

Type guard

static boolean isValidDriverInfo(DriverInfo d) {
  return d != null;
}

Try / catch

try {
  builder = DriverInfo.builder(existing);
} catch (JedisValidationException e) {
  builder = DriverInfo.builder(); // fall back to a fresh builder
}

Prevention

When it happens

Trigger: Calling DriverInfo.builder(existing) where the existing reference is null — typically a variable or getter result that was never initialized, a map/config lookup that returned null, or a method parameter forwarded without a null check.

Common situations: Library wrapper code composing driver info (e.g. Spring/Spring Data sessions tracking upstream drivers) passing an uninitialized DriverInfo; reflection or DI wiring producing null; copying driver info from an optional config that is absent.

Related errors


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

Appendix: source

Thrown at src/main/java/redis/clients/jedis/DriverInfo.java:58

  /**
   * Creates a new {@link Builder} with default values.
   * <p>
   * The default name is "Jedis" (from {@link JedisMetaInfo#getArtifactId()}).
   * @return a new builder instance
   */
  public static Builder builder() {
    return new Builder();
  }

  /**
   * Creates a new {@link Builder} initialized with values from an existing {@link DriverInfo}.
   * @param driverInfo the existing driver info to copy from, must not be {@code null}
   * @return a new builder instance initialized with the existing values
   * @throws JedisValidationException if driverInfo is {@code null}
   */
  public static Builder builder(DriverInfo driverInfo) {
    if (driverInfo == null) {
      throw new JedisValidationException("DriverInfo must not be null");
    }
    return new Builder(driverInfo);
  }

  /**
   * Returns the formatted name including upstream drivers or legacy suffix.
   * <p>
   * If a legacy suffix is set, returns the name followed by the suffix in parentheses. Otherwise,
   * if upstream drivers are present, returns the name followed by upstream drivers in parentheses,
   * separated by semicolons. If neither is set, returns just the name.
   * <p>
   * Examples:
   * <ul>
   * <li>{@code "jedis"} - no upstream drivers or suffix</li>
   * <li>{@code "jedis(my-suffix)"} - legacy suffix mode</li>
   * <li>{@code "jedis(spring-data-redis_v3.2.0)"} - one upstream driver</li>
   * <li>{@code "jedis(spring-session_v3.3.0;spring-data-redis_v3.2.0)"} - multiple upstream
   * drivers</li>

View on GitHub (pinned to 6dac31d4c2)