What causes "Empty method name (operationId) not allowed" in OpenAPITools/openapi-generator?

Add an explicit, unique, alphanumeric operationId to every operation in the spec.

OpenAPITools/openapi-generator · error · RuntimeException

Empty method name (operationId) not allowed

Error message

Empty method name (operationId) not allowed

What it means

The Swift 6 generator derives the method name from operationId via sanitizeName plus camelization and rejects an empty result, since Swift methods need a valid identifier. This is the Swift 6 port of the same guard the Swift 5 generator applies.

Source

Thrown at modules/openapi-generator/src/main/java/org/openapitools/codegen/languages/Swift6ClientCodegen.java:986

    @Override
    public String toModelDocFilename(String name) {
        return toModelName(name);
    }

    @Override
    public String toApiDocFilename(String name) {
        return toApiName(name);
    }

    @Override
    public String toOperationId(String operationId) {
        operationId = camelize(sanitizeName(operationId), LOWERCASE_FIRST_LETTER);

        // Throw exception if method name is empty.
        // This should not happen but keep the check just in case
        if (StringUtils.isEmpty(operationId)) {
            throw new RuntimeException("Empty method name (operationId) not allowed");
        }

        // method name cannot use reserved keyword, e.g. return
        if (isReservedWord(operationId)) {
            String newOperationId = camelize(("call_" + operationId), LOWERCASE_FIRST_LETTER);
            LOGGER.warn("{} (reserved word) cannot be used as method name. Renamed to {}", operationId, newOperationId);
            return newOperationId;
        }

        // operationId starts with a number
        if (operationId.matches("^\\d.*")) {
            LOGGER.warn("{} (starting with a number) cannot be used as method name. Renamed to {}", operationId, camelize(sanitizeName("call_" + operationId), LOWERCASE_FIRST_LETTER));
            operationId = camelize(sanitizeName("call_" + operationId), LOWERCASE_FIRST_LETTER);
        }

        return operationId;
    }

View on GitHub (pinned to fcec517be3)

Solutions

Add an explicit, unique, alphanumeric operationId to every operation in the spec.
Replace symbol-only operationIds with real identifiers.
Enforce an operationId-required lint rule in the spec pipeline.

Example fix

# before
paths:
  /pets/{id}:
    delete:
      operationId: '///'

# after
paths:
  /pets/{id}:
    delete:
      operationId: deletePet

Defensive patterns

Strategy: validation

Validate before calling

// node
const bad = Object.entries(spec.paths)
  .flatMap(([p, item]) => Object.values(item).filter(op => op && op.responses)
    .filter(op => !op.operationId || !/[a-zA-Z0-9]/.test(op.operationId)));
if (bad.length) throw new Error('operations without usable operationId: ' + bad.length);

Type guard

const isValidOperationId = (id: unknown): id is string =>
  typeof id === 'string' && /[a-zA-Z0-9]/.test(id);

Try / catch

// Java
try { new DefaultGenerator().opts(input).generate(); }
catch (RuntimeException e) {
    // empty-name guard: fix the spec, never retry the same input
}

Prevention

Lint operationId presence before any generator run.
When porting specs to the swift6 generator, diff for empty or symbol-only ids.
Automate id generation (method + path camelization) in the spec pipeline if hand-authoring is error-prone.

When it happens

Trigger: An operation has no operationId, or an operationId like '///', '-' or whitespace that sanitizes to an empty string after camelization.

Common situations: Migrating a project to the swift6 generator with a spec that previously squeaked by; specs with symbol-only operationIds; generated specs where operationId fields are conditionally emitted.

Related errors

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