quarkusio/quarkus · error · RuntimeException

Failed to process ${path}

Error message

Failed to process ${path}

What it means

ApplicationArchiveBuildStep's index cache computes a Jandex Index for each archive JAR via IndexingUtil.indexJar; an IOException during indexing is wrapped as RuntimeException 'Failed to process <path>'. This occurs while Quarkus builds the application index of dependency archives at augmentation time.

Source

Thrown at core/deployment/src/main/java/io/quarkus/deployment/index/ApplicationArchiveBuildStep.java:362

        Indexer indexer = new Indexer();
        for (Path path : classFilesToIndex) {
            try (InputStream in = Files.newInputStream(path)) {
                indexer.index(in);
            } catch (IOException e) {
                throw new RuntimeException(e);
            }
        }
        return indexer.complete();
    }

    private static Index handleJarPath(Path path, IndexCache indexCache, Set<String> removed) {
        return indexCache.cache.computeIfAbsent(path, new Function<Path, Index>() {
            @Override
            public Index apply(Path path) {
                try {
                    return IndexingUtil.indexJar(path, removed);
                } catch (IOException e) {
                    throw new RuntimeException("Failed to process " + path, e);
                }
            }
        });
    }

    /**
     * When running in hot deployment mode we know that java archives will never change, there is no need
     * to re-index them each time. We cache them here to reduce the hot reload time.
     */
    private static final class IndexCache {
        final Map<Path, Index> cache = new HashMap<>();
    }
}

View on GitHub (pinned to e1c734241f)

Solutions

  1. Delete the offending JAR from the local repo and rebuild (e.g. find ~/.m2 -name '*.jar' corrupted one; rm; mvn again)
  2. Run ./mvnw clean and clear build caches if a copied artifact is truncated
  3. Check file permissions/readability of the JAR inside the container/CI workspace
  4. Refresh dependency caches in CI (re-download instead of reusing suspect cache)

Example fix

// before: corrupt artifact in ~/.m2
rm -rf ~/.m2/repository/org/acme/broken-artifact
// after: re-download
./mvnw -U clean package
Defensive patterns

Strategy: validation

Validate before calling

Path jar = Path.of(pathToArchive);
if (!Files.isRegularFile(jar) || Files.size(jar) == 0 || !isReadableZip(jar)) {
    throw new IllegalStateException("Invalid archive JAR: " + jar + " — delete from ~/.m2 and re-download");
}

Type guard

static boolean looksLikeJar(Path p) {
    try {
        if (!Files.isRegularFile(p) || Files.size(p) < 4) return false;
        byte[] head = new byte[4];
        try (var in = Files.newInputStream(p)) { in.readNBytes(head, 0, 4); }
        return head[0]=='P' && head[1]=='K'; // zip magic
    } catch (IOException e) { return false; }
}

Try / catch

try {
    buildArchives();
} catch (RuntimeException e) {
    if (e.getMessage().startsWith("Failed to process ")) {
        Path bad = Path.of(e.getMessage().replace("Failed to process ", ""));
        Files.deleteIfExists(Path.of(System.getProperty("user.home"), ".m2", ...)); // then re-resolve
    }
    throw e;
}

Prevention

When it happens

Trigger: computeIfAbsent(...).apply(path) on an archive JAR whose file cannot be read: missing, truncated, corrupt zip, or unreadable due to permissions, during quarkus build/augment.

Common situations: Corrupted JAR in local Maven repository (~/.m2) from an interrupted download; partially copied dependencies in CI cache; classpath JAR deleted/replaced while build runs; unreadable file permissions in container images.

Related errors


AI-assisted analysis of quarkusio/quarkus@e1c734241f (2026-09-05). Data as JSON: /api/errors/98df67d832bb1ced. Report an issue: GitHub.