apache/iceberg · error · ValidationException

Delta Lake table at %s contains no constructable snapshot

Error message

Delta Lake table at %s contains no constructable snapshot

What it means

ValidationException thrown when snapshotting a Delta Lake table fails to find any snapshot version that can be constructed into an Iceberg snapshot; every attempted start version raised NotFoundException, IllegalArgumentException, or DeltaStandaloneException.

Source

Thrown at delta-lake/src/main/java/org/apache/iceberg/delta/BaseSnapshotDeltaLakeTableAction.java:269

        for (AddFile addFile : initDataFiles) {
          DataFile dataFile = buildDataFileFromAction(addFile, transaction.table());
          filesToAdd.add(dataFile);
          migratedDataFilesBuilder.add(dataFile.location());
        }

        // AppendFiles case
        AppendFiles appendFiles = transaction.newAppend();
        filesToAdd.forEach(appendFiles::appendFile);
        appendFiles.commit();
        tagCurrentSnapshot(constructableStartVersion, transaction);

        return constructableStartVersion;
      } catch (NotFoundException | IllegalArgumentException | DeltaStandaloneException e) {
        constructableStartVersion++;
      }
    }

    throw new ValidationException(
        "Delta Lake table at %s contains no constructable snapshot", deltaTableLocation);
  }

  /**
   * Iterate through the {@code VersionLog} to determine the update type and commit the update to
   * the given {@code Transaction}.
   *
   * <p>There are 3 cases:
   *
   * <p>1. AppendFiles - when there are only AddFile instances (an INSERT on the table)
   *
   * <p>2. DeleteFiles - when there are only RemoveFile instances (a DELETE where all the records of
   * file(s) were removed)
   *
   * <p>3. OverwriteFiles - when there are a mix of AddFile and RemoveFile (a DELETE/UPDATE)
   *
   * @param versionLog the delta log version to commit to iceberg table transaction
   * @param transaction the iceberg table transaction to commit to

View on GitHub (pinned to 86d9c8fc54)

Solutions

Verify deltaTableLocation points to a valid Delta table with an intact _delta_log
Start the incremental snapshot from a valid, still-present version (not vacuumed away)
Run the full (non-incremental) migration once to establish a valid base snapshot

Example fix

// before
actions.SnapshotDeltaLakeTable(deltaTable, "incremental").toIncrementalSnapshotVersion(42)...
// after
// choose a version whose log files still exist (not vacuumed), or run full migration
actions.SnapshotDeltaLakeTable(deltaTable).execute();

Defensive patterns

Strategy: validation

Try / catch

try { action.execute(); } catch (ValidationException e) { /* fall back to full snapshot migration */ }

Prevention

Verify the Delta table location and _delta_log integrity before migration
Choose start versions whose log files have not been vacuumed
Run a full migration before attempting incremental snapshots

When it happens

Trigger: Running SnapshotDeltaLakeTable with a startSnapshotVersion/toIncrementalSnapshotVersion that is unusable and no constructable version exists, or the Delta log at deltaTableLocation is unreadable/corrupt at every candidate version.

Common situations: Wrong delta table location, missing/incomplete Delta transaction logs, incremental migration from an invalid version after table compaction/vacuum removed needed files.

Understand the failure class

Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.

Related errors

AI-assisted analysis of apache/iceberg@86d9c8fc54 (2026-09-12). Data as JSON: /api/errors/26395a3b49083a98. Report an issue: GitHub.