apache/hadoop · error · IOException

Error converting TxidResponseProto: got a transaction id {}

Error message

Error converting TxidResponseProto: got a transaction id {} that was outside the range of [{}, {}].

What it means

Each EventBatchProto in an inotify response must carry a txid inside the envelope's [firstTxid, lastTxid] window (or the sentinel -1). A batch outside that window means the response is internally inconsistent - typically a NameNode bug or protocol/version skew - and event ordering can no longer be trusted, so conversion throws IOException.

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs-client/src/main/java/org/apache/hadoop/hdfs/protocolPB/PBHelperClient.java:887

      policies[i++] = convert(proto);
    }
    return policies;
  }

  public static EventBatchList convert(GetEditsFromTxidResponseProto resp)
      throws IOException {
    final InotifyProtos.EventsListProto list = resp.getEventsList();
    final long firstTxid = list.getFirstTxid();
    final long lastTxid = list.getLastTxid();

    List<EventBatch> batches = Lists.newArrayList();
    if (list.getEventsList().size() > 0) {
      throw new IOException("Can't handle old inotify server response.");
    }
    for (InotifyProtos.EventBatchProto bp : list.getBatchList()) {
      long txid = bp.getTxid();
      if ((txid != -1) && ((txid < firstTxid) || (txid > lastTxid))) {
        throw new IOException("Error converting TxidResponseProto: got a " +
            "transaction id " + txid + " that was outside the range of [" +
            firstTxid + ", " + lastTxid + "].");
      }
      List<Event> events = Lists.newArrayList();
      for (InotifyProtos.EventProto p : bp.getEventsList()) {
        switch (p.getType()) {
        case EVENT_CLOSE:
          InotifyProtos.CloseEventProto close =
              InotifyProtos.CloseEventProto.parseFrom(p.getContents());
          events.add(new Event.CloseEvent(close.getPath(),
              close.getFileSize(), close.getTimestamp()));
          break;
        case EVENT_CREATE:
          InotifyProtos.CreateEventProto create =
              InotifyProtos.CreateEventProto.parseFrom(p.getContents());
          Event.CreateEvent.Builder builder = new Event.CreateEvent.Builder()
                  .iNodeType(createTypeConvert(create.getType()))
                  .path(create.getPath())

View on GitHub (pinned to 2add963021)

Solutions

  1. Retry the inotify fetch starting from the last successfully processed txid
  2. Verify all NameNodes run the same version and check NN logs for edit-tailing anomalies
  3. If reproducible, capture the reported txid/window values and upgrade the affected component - the inconsistency originates server-side
Defensive patterns

Strategy: retry

Try / catch

try {
  batches = convert(resp);
} catch (IOException e) {
  if (e.getMessage() != null && e.getMessage().contains("outside the range")) {
    batches = inotifyFetch(lastSeenTxid); // refetch from checkpoint; report if persistent
  } else {
    throw e;
  }
}

Prevention

When it happens

Trigger: getEditsFromTxid returns batches whose bp.getTxid() is less than firstTxid or greater than lastTxid while PBHelperClient.convert(GetEditsFromTxidResponseProto) walks the batch list.

Common situations: Rare; observed with NameNode bugs around concurrent edit tailing, mixed NN versions during rolling upgrade, or corrupted RPC responses.

Related errors


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