elastic/elasticsearch · error · RuntimeException

Version {} already exists in TransportVersions.csv with tran

Error message

Version {} already exists in TransportVersions.csv with transport version ID {}, but expected {}

What it means

Thrown by the UpdateTransportVersionsCSVTask Gradle task when regenerating TransportVersions.csv. The task recomputes the expected transport version ID for a stack version from its declared upper bound, then checks the existing CSV row for idempotency. If the row is present but its recorded ID disagrees with the freshly computed one, the task aborts rather than silently rewriting committed data.

Source

Thrown at build-tools-internal/src/main/java/org/elasticsearch/gradle/internal/transport/UpdateTransportVersionsCSVTask.java:55

    @TaskAction
    public void run() throws IOException {
        Version stackVersion = Version.fromString(getStackVersion().get());
        String upperBoundName = getUpperBoundName(stackVersion);
        TransportVersionResourcesService resources = getResourceService().get();
        TransportVersionUpperBound upperBound = resources.getUpperBoundFromGitBase(upperBoundName);

        if (upperBound == null) {
            throw new RuntimeException("Missing upper bound " + upperBoundName + " for stack version " + stackVersion);
        }

        int expectedTransportVersionId = upperBound.definitionId().complete();

        // Check if this version is already in the CSV file (idempotency check)
        Integer existingTransportVersionId = getExistingTransportVersionId(stackVersion);
        if (existingTransportVersionId != null) {
            if (existingTransportVersionId != expectedTransportVersionId) {
                throw new RuntimeException(
                    "Version "
                        + stackVersion
                        + " already exists in TransportVersions.csv with transport version ID "
                        + existingTransportVersionId
                        + ", but expected "
                        + expectedTransportVersionId
                );
            }
            getLogger().lifecycle(
                "Version {} already exists in TransportVersions.csv with correct transport version ID, skipping",
                stackVersion
            );
            return;
        }

        addTransportVersionRecord(stackVersion, expectedTransportVersionId);
    }

View on GitHub (pinned to db6a809a66)

Solutions

1. Inspect the named upper bound file for the stack version and confirm definitionId().complete() matches the value the task expects; revert any unintended edits to that upper bound.
2. If the CSV row is genuinely stale, delete the offending row from TransportVersions.csv and rerun './gradlew generateTransportVersion' to regenerate it from the current upper bound.
3. If the upper bound itself was changed intentionally, coordinate with the transport-version owner — a released version's ID must never change, so the fix is usually to restore the original upper bound and allocate a new version for the new wire change instead.

Example fix

// before: upper bound edited so stackVersion 9.0.0 now yields id 1234, but CSV still says 1230
// after: revert the upper bound file, then add a NEW upper bound for the new wire change instead
//   git checkout -- <upper-bound-file>
//   ./gradlew generateTransportVersion

// Before running generateTransportVersion, confirm the upper bound for the stack version is committed and unchanged:
// git diff --name-only -- <upper-bound-path>   (should be empty unless you intend a new allocation)
// Run the task only on a clean tree matching the intended ID assignment.

When it happens

Trigger: Running './gradlew generateTransportVersion' (or any task wiring UpdateTransportVersionsCSVTask) after the upper-bound definition for an already-released stack version was edited, so the same stack version string now maps to a different definitionId().complete(). Also when a CSV row was hand-edited or cherry-picked from a branch with a different ID assignment.

Common situations: Backporting a transport-version change across branches where the ID allocation diverged; rebasing a PR whose upper-bounds file conflicts with a merged change; manually editing TransportVersions.csv; switching between feature branches that each allocated a different ID for the same version name.

Related errors

• TransportVersion.fromName("{}") was used at {}, but lacks a
• Invalid tag format [{l}]
• Output file not specified
• No version ids found in {javaVersionsFile}
• Invalid version format: '{s}'. Should be {pattern}

AI-assisted analysis of elastic/elasticsearch@db6a809a66 (2026-08-12). Data as JSON: /api/errors/1d2a2c5175109686. Report an issue: GitHub.