What causes "missing config!" in OpenAPITools/openapi-generator?

Use CodegenConfigurator end-to-end: set inputSpec AND generatorName, then toClientOptInput() - this loads the CodegenConfig via CodegenConfigLoader.forName and never leaves config null.

OpenAPITools/openapi-generator · error · RuntimeException

missing config!

Error message

missing config!

What it means

The second guard in DefaultGenerator.generate(): after verifying openAPI it verifies config (the CodegenConfig carrying the generator instance and all options). A null config means opts(...) was never called or the ClientOptInput carried no CodegenConfig - practically the same setup-ordering bug as error [8], just one check later. It cannot fire if openAPI was also null (the first guard throws first), so seeing it means a spec WAS attached but the generator config was not.

Source

Thrown at modules/openapi-generator/src/main/java/org/openapitools/codegen/DefaultGenerator.java:1281

            if (ProcessUtils.hasHttpBasicMethods(authMethods)) {
                bundle.put("hasHttpBasicMethods", true);
                bundle.put("httpBasicMethods", ProcessUtils.getHttpBasicMethods(authMethods));
            }
            if (ProcessUtils.hasApiKeyMethods(authMethods)) {
                bundle.put("hasApiKeyMethods", true);
                bundle.put("apiKeyMethods", ProcessUtils.getApiKeyMethods(authMethods));
            }
        }
    }

    @Override
    public List<File> generate() {
        if (openAPI == null) {
            throw new RuntimeException("Issues with the OpenAPI input. Possible causes: invalid/missing spec, malformed JSON/YAML files, etc.");
        }

        if (config == null) {
            throw new RuntimeException("missing config!");
        }

        if (config.getGeneratorMetadata() == null) {
            LOGGER.warn("Generator '{}' is missing generator metadata!", config.getName());
        } else {
            GeneratorMetadata generatorMetadata = config.getGeneratorMetadata();
            if (StringUtils.isNotEmpty(generatorMetadata.getGenerationMessage())) {
                LOGGER.info(generatorMetadata.getGenerationMessage());
            }

            Stability stability = generatorMetadata.getStability();
            String stabilityMessage = String.format(Locale.ROOT, "Generator '%s' is considered %s.", config.getName(), stability.value());
            if (stability == Stability.DEPRECATED) {
                LOGGER.warn(stabilityMessage);
            } else {
                LOGGER.info(stabilityMessage);
            }
        }

View on GitHub (pinned to fcec517be3)

Solutions

Use CodegenConfigurator end-to-end: set inputSpec AND generatorName, then toClientOptInput() - this loads the CodegenConfig via CodegenConfigLoader.forName and never leaves config null.
If wiring manually, ensure ClientOptInput's config is set from CodegenConfigLoader.forName(generatorName) before generator.opts(input).
Guard your own code: assert input.getConfig() != null && input.getOpenAPI() != null before calling generate() so misuse fails with your own message.
On the CLI, pass both -i <spec> and -g <generator>.

Example fix

// before
ClientOptInput input = new ClientOptInput();
input.setOpenAPI(parsedSpec);
new DefaultGenerator().opts(input).generate(); // missing config!
// after
ClientOptInput input = new ClientOptInput();
input.setOpenAPI(parsedSpec);
input.setConfig(CodegenConfigLoader.forName("java"));
new DefaultGenerator().opts(input).generate();

Defensive patterns

Strategy: validation

Validate before calling

// Assert the pipeline is fully wired before generate()
Objects.requireNonNull(input.getOpenAPI(), "spec missing");
Objects.requireNonNull(input.getConfig(), "generator config missing (set generatorName)");
new DefaultGenerator().opts(input).generate();

Try / catch

try {
    new DefaultGenerator().opts(input).generate();
} catch (RuntimeException e) {
    if ("missing config!".equals(e.getMessage())) {
        // CodegenConfigLoader never ran: set generatorName on CodegenConfigurator and rebuild input
        throw new IllegalStateException("ClientOptInput built without CodegenConfig", e);
    }
    throw e;
}

Prevention

Use CodegenConfigurator with BOTH setInputSpec and setGeneratorName before toClientOptInput().
Never reuse a ClientOptInput across different generator configurations.
Add unit coverage for your generation entrypoint so setup regressions fail in tests, not production.

When it happens

Trigger: Calling generate() after a partial setup that set the spec but not the generator (hand-built ClientOptInput with only openAPI set); a wrapper that built CodegenConfigurator but called toClientOptInput() before setGeneratorName so CodegenConfigLoader never ran; error-path code that reuses a half-configured generator instance.

Common situations: Programmatic integrations migrating between openapi-generator versions whose ClientOptInput shape changed; test scaffolding that constructs input objects directly; on-demand generation services that short-circuit config construction on a cached-spec path.

Related errors

AI-assisted analysis of OpenAPITools/openapi-generator@fcec517be3 (2026-08-22). Data as JSON: /api/errors/f585ec49488f0aa6. Report an issue: GitHub.