OpenAPITools / OpenAPITools/openapi-generator
[BUG] protobuf-schema generator wraps standalone enums in message types but does not update field references
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 26.8k
- Forks
- 7.7k
- PR merge metrics
- PR metrics pending
Description
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 emptyResourceTypemessage object instead of an enum valueResourceType.RESOURCE_TYPE_SYNCno longer compiles (the constants are now onResourceType.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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with ProtobufSchemaCodegen.java and compare its field-reference handling with the enum.mustache change introduced by #22740. Reproduce the issue using the minimal OpenAPI YAML and protobuf-schema generator options described in the report. Done means generated fields reference the nested enum type while standalone enums retain the expected values.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- tooling
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 76/100