apache/hadoop · error · IllegalArgumentException

The creation time for the record cannot be negative.

Error message

The creation time for the record cannot be negative.

What it means

BaseRecord.validate() runs when a record is created, populated from the state store, and before committing to it. It requires dateCreated > 0; a missing or zero creation timestamp throws IllegalArgumentException(ERROR_MSG_CREATION_TIME_NEGATIVE). Records normally get their timestamps defaulted when persisted, so this fires on records whose creation date was never set — typically deserialized legacy data or programmatically built records that skipped initialization.

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs-rbf/src/main/java/org/apache/hadoop/hdfs/server/federation/store/records/BaseRecord.java:260

   */
  public boolean shouldBeDeleted(long currentTime) {
    long deletionTime = getDeletionMs();
    if (isExpired() && deletionTime > 0) {
      long elapsedTime = currentTime - (getDateModified() + getExpirationMs());
      return elapsedTime > deletionTime;
    } else {
      return false;
    }
  }

  /**
   * Validates the record. Called when the record is created, populated from the
   * state store, and before committing to the state store. If validate failed,
   * there throws an exception.
   */
  public void validate() {
    if (getDateCreated() <= 0) {
      throw new IllegalArgumentException(ERROR_MSG_CREATION_TIME_NEGATIVE);
    } else if (getDateModified() <= 0) {
      throw new IllegalArgumentException(ERROR_MSG_MODIFICATION_TIME_NEGATIVE);
    }
  }

  @Override
  public String toString() {
    return getPrimaryKey();
  }
}

View on GitHub (pinned to 2add963021)

Solutions

  1. Identify the failing record class from the logs and rebuild that state store data — membership and mounts regenerate from heartbeats/config after the stale entries are removed.
  2. If you maintain a custom record type, default the timestamps: set dateCreated/dateModified to Time.now() in the constructor or before put().
  3. For upgrades, clear (or migrate with timestamps filled) the dev/test state store rather than reusing old rows.
  4. If writing records programmatically, always go through the builder/newInstance path that stamps dates on commit.

Example fix

// before: record validated/committed without a creation date
MembershipState m = MembershipState.newInstance();
m.setNameserviceId("ns1");
store.put(m); // validate() -> IllegalArgumentException

// after: stamp both timestamps before committing
m.setDateCreated(Time.now());
m.setDateModified(Time.now());
store.put(m);
Defensive patterns

Strategy: validation

Validate before calling

// Stamp timestamps before validate/put
long now = Time.now();
record.setDateCreated(now);
record.setDateModified(now);
// or use the builder/newInstance path that defaults dates on commit

Try / catch

try {
  record.validate();
} catch (IllegalArgumentException e) {
  if (e.getMessage().contains("creation time")) {
    record.setDateCreated(Time.now()); // repair in dev tooling; investigate source in prod
    record.validate();
  } else { throw e; }
}

Prevention

When it happens

Trigger: Reading state store rows written by an older Hadoop version that did not populate dateCreated; manually inserted or migrated records lacking the column value; custom BaseRecord subclasses constructed via newInstance and put into the store without setting timestamps before validate().

Common situations: RBF upgrade with old persisted membership/mount records; hand-edited or migrated state store; a new custom record implementation forgetting timestamp initialization; test fixtures building records directly.

Related errors


AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22). Data as JSON: /api/errors/053900b7e3931bca. Report an issue: GitHub.