apache/hadoop · error · IOException

No edits file for txid " + startTxId + "-" + endTxId + " exi

Error message

No edits file for txid " + startTxId + "-" + endTxId + " exists!

What it means

findFinalizedEditsFile scans EDITS-type storage directories for the finalized segment file edits_starttxid-endtxid and throws when no directory contains it. It is called from edit-log tailing, checkpoint alignment and recovery flows whenever a specific finalized segment must exist on local storage.

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/NNStorage.java:827

    return String.format("%s_%019d-%019d", NameNodeFile.EDITS.getName(),
                         startTxId, endTxId);
  }

  public static String getTemporaryEditsFileName(long startTxId, long endTxId,
      long timestamp) {
    return String.format("%s_%019d-%019d_%019d",
        NameNodeFile.EDITS_TMP.getName(), startTxId, endTxId, timestamp);
  }
  
  /**
   * Return the first readable finalized edits file for the given txid.
   */
  File findFinalizedEditsFile(long startTxId, long endTxId)
  throws IOException {
    File ret = findFile(NameNodeDirType.EDITS,
        getFinalizedEditsFileName(startTxId, endTxId));
    if (ret == null) {
      throw new IOException(
          "No edits file for txid " + startTxId + "-" + endTxId + " exists!");
    }
    return ret;
  }
    
  /**
   * Return the first readable image file for the given txid and image type, or
   * null if no such image can be found.
   */
  File findImageFile(NameNodeFile nnf, long txid) {
    return findFile(NameNodeDirType.IMAGE,
        getNameNodeFileName(nnf, txid));
  }

  /**
   * Return the first readable storage file of the given name
   * across any of the 'current' directories in SDs of the
   * given type, or null if no such file exists.

View on GitHub (pinned to 2add963021)

Solutions

  1. List the finalized edits_* files actually present under each dfs.namenode.edits.dir and confirm the requested range is truly absent.
  2. If purged, re-sync via a fresh checkpoint: the peer downloads the current image and only tails edits from its txid onward, no old segment needed.
  3. Restore missing segments from JournalNodes (qjm) or backups before retrying recovery or tailing.
  4. For 'hdfs namenode -recover', answer the prompt to skip the missing segment when offered.
Defensive patterns

Strategy: validation

Validate before calling

// Before requesting a segment, confirm it is present locally
File[] present = new File(editsDir, "current").listFiles((d, n) ->
    n.equals(String.format("edits_%019d-%019d", startTxId, endTxId)));
if (present == null || present.length == 0) {
  // fall back to syncing from the current image instead of asking for a purged segment
  throw new FileNotFoundException("Finalized segment " + startTxId + "-" + endTxId + " not on local storage");
}

Try / catch

try {
  return storage.findFinalizedEditsFile(startTxId, endTxId);
} catch (IOException e) {
  if (e.getMessage() != null && e.getMessage().startsWith("No edits file for txid")) {
    LOG.warn("Segment purged or absent; re-syncing from latest image instead");
    return downloadLatestImageAndTail();
  }
  throw e;
}

Prevention

When it happens

Trigger: Requesting a segment (getEdit download, recovery replay, rollback target) that was already purged by retention, deleted manually, lives only on an unavailable journal (NFS down, JournalNodes expelled), or whose txid range is simply wrong in tooling.

Common situations: Standby/2NN catching up asks for an old segment the Active already purged after checkpointing; a namespace restored from backup whose local edits are ahead or behind; manual pruning of edits dirs; retention settings aggressively deleting segments.

Related errors


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