Skip to content

[BUG] protobuf-schema generator wraps standalone enums in message types but does not update field references #23559

@NielsDoucet

Description

@NielsDoucet

Bug Report Checklist

  • Have you provided a full/minimal spec to reproduce the issue?
  • Have you validated the input using an OpenAPI validator?
  • Have you tested with the latest master to confirm the issue still exists?
  • Have you searched for related issues/PRs?
  • What's the actual output vs expected output?
  • [Optional] Sponsorship to speed up the bug fix or feature request (example)
Description

Since 7.20.0, in the protobuf-schema generator, standalone enum schemas (top-level $ref enums in OpenAPI) are unconditionally wrapped in a message type with a nested Enum:

v7.19.0:

enum ResourceType {
  RESOURCE_TYPE_UNSPECIFIED = 0;
  RESOURCE_TYPE_SYNC = 1;
  RESOURCE_TYPE_ASYNC = 2;
}

v7.20.0+:

message ResourceType {
  enum Enum {
    RESOURCE_TYPE_UNSPECIFIED = 0;
    RESOURCE_TYPE_SYNC = 1;
    RESOURCE_TYPE_ASYNC = 2;
  }
}

However, field references to that enum in other generated messages are not updated. Instead they still use the bare type name:

message BulkOperationMessage {
  ResourceType resource_type = 5;  // ResourceType is now a message, not an enum
}

The field should reference the nested enum type:

message BulkOperationMessage {
  ResourceType.Enum resource_type = 5;  // correct
}

The generated .proto files are syntactically valid but semantically broken. ResourceType is now an empty message, so the resource_type field carries no information. In Java:

  • message.getResourceType() returns an empty ResourceType message object instead of an enum value
  • ResourceType.RESOURCE_TYPE_SYNC no longer compiles (the constants are now on ResourceType.Enum)
  • message.getResourceType().name() does not compile (no .name() method on a proto message)

Affected versions: 7.20.0, 7.21.0 (confirmed working: 7.19.0)

openapi-generator version

7.21.0
protobuf-schema generator

OpenAPI declaration file content or url

Minimal reproducer spec:

components:                                                                                                                                                                                 
  schemas:                                                
    ResourceType:
      type: string
      enum:
        - SYNC
        - ASYNC                                                                                                                                                                             
 
    BulkOperationMessage:                                                                                                                                                                   
      type: object                                        
      properties:
        resourceType:
          $ref: '#/components/schemas/ResourceType'
Generation Details

Generation through the gradle plugin, with the following additional options set:

generatorName = "protobuf-schema"
library = ""
configOptions.put("startEnumsWithUnspecified", "true")
configOptions.put("numberedFieldNumberList", "true")
Steps to reproduce
Related issues/PRs

Introduced by: #22740 (merged 2026-01-30)

Suggest a fix

enum.mustache was changed to always generate the message wrapper, but the field-reference was not updated to match. The two halves of the generated output are inconsistent with each other.
This should be fixed in ProtobufSchemaCodegen.java: when setting x-protobuf-data-type for a property whose $ref target is a wrapped enum (i.e. isEnum is true on the referenced model), it should set the value to ResourceType.Enum instead of ResourceType.

Workaround

There is a workaround possible, by reverting the enum.mustache file to its v7.19.0 state. This reverts the generated enums to a flat structure.
The gradle plugin provides a templateDir option to allow for that.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions