elastic/elasticsearch · error · IllegalArgumentException

No version ids found in {javaVersionsFile}

Error message

No version ids found in {javaVersionsFile}

What it means

Thrown by ExtractCurrentVersionsTask.readLatestVersion after walking all FieldDeclaration nodes in the parsed Version.java file via a FieldIdExtractor. If the extractor's highestVersionId remains null (no field yielded an integer id), the file did not contain any recognizable version-id field declarations and the task cannot determine the latest version.

Source

Thrown at build-tools-internal/src/main/java/org/elasticsearch/gradle/internal/release/ExtractCurrentVersionsTask.java:90

        @Override
        public void accept(FieldDeclaration fieldDeclaration) {
            findSingleIntegerExpr(fieldDeclaration).ifPresent(id -> {
                if (highestVersionId != null && highestVersionId > id) {
                    LOGGER.warn("Version ids [{}, {}] out of order", highestVersionId, id);
                } else {
                    highestVersionId = id;
                }
            });
        }
    }

    private static int readLatestVersion(Path javaVersionsFile) throws IOException {
        CompilationUnit java = StaticJavaParser.parse(javaVersionsFile);

        FieldIdExtractor extractor = new FieldIdExtractor();
        java.walk(FieldDeclaration.class, extractor);   // walks in code file order
        if (extractor.highestVersionId == null) {
            throw new IllegalArgumentException("No version ids found in " + javaVersionsFile);
        }
        return extractor.highestVersionId;
    }
}

View on GitHub (pinned to db6a809a66)

Solutions

1. Open the named javaVersionsFile and confirm it still contains simple `public static final int <NAME> = <int>;` version-id fields.
2. If a field legitimately contains multiple integer literals, it is intentionally skipped (logged as a warning) — ensure at least one single-integer field exists for the extractor to use.
3. If the file format changed, update FieldIdExtractor / findSingleIntegerExpr to match the new structure rather than weakening the check.
4. Verify the file path constant INDEX_VERSIONS_FILE_PATH / passed path points at the correct source file.

// After extraction, ensure a result was found
if (extractor.highestVersionId == null) {
    throw new IllegalStateException("No version ids parsed from " + javaVersionsFile
        + " — verify the file still contains simple int literal version fields");
}

When it happens

Trigger: StaticJavaParser parses the javaVersionsFile (typically Version.java) and a FieldIdExtractor walks its FieldDeclarations looking for integer literals. If none matched the extractor's criteria (e.g. all candidate fields have zero or multiple integer literals, or the file structure changed), highestVersionId stays null and the throw fires.

Common situations: Version.java was refactored so version ids are no longer simple integer literal fields (e.g. moved to a map, computed, or annotated in a new way); the file path constant points at the wrong file; the extractor's matching logic didn't evolve with the source format; a parsing edge case where a version field has multiple integer literals and is skipped per findSingleIntegerExpr's default branch.

Related errors

• Invalid tag format [{l}]
• CompilationUnit has no lexical information for output
• Output file not specified
• Invalid version format: '{s}'. Should be {pattern}
• 'branch' not specified.

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