Scarab Diagnostic Field Test #027 has landed upstream.
Target: OpenAPITools/openapi-generator
Issue: OpenAPITools/openapi-generator#23550
PR: OpenAPITools/openapi-generator#24022
Status: merged
Milestone: 7.24.0
This field test targeted a Kotlin generator bug in OpenAPI Generator where an OpenAPI 3.1 boolean const: true schema value was rendered into generated Kotlin source as the string "true" instead of the boolean literal true.
That sounds small.
It is small.
That is why it matters.
In code generation, a tiny boundary mistake can become a broken downstream project. A generator does not get to be “almost right” when it emits source code. If the schema says boolean, the generated target-language literal has to preserve that boolean truth.
In this case, the generated enum value type was kotlin.Boolean, but the generator emitted "true" as a string literal.
The generated Kotlin did not compile.
The patch was accepted, added to the 7.24.0 milestone, and merged upstream.
The issue shape
The visible issue was simple:
An OpenAPI 3.1 schema defined a boolean constant value.
The Kotlin generator produced a model where the enum value type was kotlin.Boolean.
But the emitted enum value was rendered as "true".
That created a type/literal mismatch:
"true"
where the generated Kotlin source needed:
true
This was not a Kotlin language problem.
It was not a user configuration problem.
It was not a broad OpenAPI 3.1 interpretation problem.
It was a generator boundary problem.
The schema truth was boolean.
The Kotlin type truth was boolean.
The emitted source literal drifted into string.
The boundary
The boundary here was:
schema-level boolean truth → target-language literal rendering
OpenAPI Generator does not merely copy schema values into files. It translates schema information into source code for a target language.
That translation layer has a responsibility.
When a schema-derived value crosses into Kotlin source text, the generated literal has to match the generated Kotlin type.
For this issue, the source schema said const: true.
The generated enum context expected kotlin.Boolean.
The literal printer emitted "true".
That is the exact boundary failure.
Not “enum generation is broken.”
Not “OpenAPI 3.1 const support needs a rewrite.”
Not “Kotlin models need a new type system.”
Just this:
a boolean schema value crossed into Kotlin source text as a string literal.
That is the repair lane.
What changed
The merged PR updates the Kotlin generator so boolean enum values are emitted as boolean literals when the target enum value type is kotlin.Boolean.
The repair follows the existing primitive-handling pattern already present for numeric values such as Int and Long.
That detail matters.
This patch did not invent a new enum system.
It did not rewrite the broader generator pipeline.
It did not change OpenAPI schema interpretation globally.
It extended the existing literal-emission behavior to cover the missing boolean case.
The PR added focused regression coverage in two places:
- a direct toEnumValue assertion for boolean literal rendering
- a generated-output regression fixture for the OpenAPI 3.1 const: true boolean case
That means the repair was protected at both the small rendering-function boundary and the generated-source output boundary.
Why this is a good field test
This is a good Scarab field test because the patch is narrow but the boundary is clean.
A generator is a chain of truth transformations.
Schema truth becomes generator metadata.
Generator metadata becomes target-language type information.
Target-language type information becomes emitted source code.
If any step in that chain changes the meaning of the value, the generated project inherits the break.
Here, the boolean value survived the schema.
It survived the target type.
It failed at literal rendering.
That is exactly the kind of failure Scarab is designed to make legible.
Not because the bug is large.
Because the ownership surface is precise.
OpenAPI Generator owns the generated Kotlin source text.
The Kotlin generator owns how schema-derived enum values are rendered into Kotlin literals.
A boolean schema value should remain boolean when emitted into a kotlin.Boolean enum context.
The patch restored that boundary.
Why the repair stayed small
The tempting mistake in generator bugs is to make the patch bigger than the failure.
OpenAPI Generator supports many target languages, schema forms, generator modes, and target-specific behaviors. A small bug can easily invite a broad abstraction change.
That would have been the wrong repair here.
The issue did not prove that enum generation was globally broken.
It did not prove that Kotlin model typing was wrong.
It did not prove that OpenAPI 3.1 const support needed a broad redesign.
It proved one narrower thing:
a boolean value that should be emitted as a Kotlin boolean literal was being emitted as a string literal.
So the patch stayed at that level.
When the failure is a missing primitive literal case, the repair should add the missing primitive literal case.
That is the discipline.
Find the boundary.
Keep the evidence close.
Patch the owning surface.
Do not turn a precise failure into a broad rewrite.
Validation
The PR included the targeted Kotlin regression coverage and full project validation.
Validation included:
./mvnw clean package
./bin/generate-samples.sh ./bin/configs/*.yaml
./bin/utils/export_docs_generators.sh
The automated review found no issues across the changed files.
The maintainer accepted the patch with:
lgtm. thanks for the fix
The PR was then added to the 7.24.0 milestone and merged.
That is the full loop:
public issue
bounded diagnostic read
narrow patch
regression coverage
maintainer acceptance
upstream merge
Field test result
This was a bounded Kotlin generator literal-emission repair for OpenAPI Generator.
The issue reduced to:
- an OpenAPI 3.1 boolean const: true schema reached the Kotlin generator
- the generated enum value type was kotlin.Boolean
- the emitted literal was incorrectly stringified as "true"
- the generated Kotlin was uncompilable
- OpenAPI Generator already had primitive literal handling for values such as Int and Long
- the Kotlin generator was missing the matching boolean literal path
- the PR added narrow boolean handling and focused regression coverage
- the patch was accepted, milestone’d, and merged upstream
That is a clean field-test result.
The patch does not claim to redesign OpenAPI 3.1 support.
It does not claim to rewrite enum generation.
It does not claim to alter Kotlin model typing broadly.
It fixes the boundary where boolean schema truth becomes Kotlin source text.
Why this matters
This is the third upstream-merged Scarab field-test repair in a major developer infrastructure project.
The pattern is becoming more important than any single patch.
pnpm merged a bounded repair.
Docker Compose merged a bounded repair.
Now OpenAPI Generator has merged a bounded repair.
Different ecosystems.
Different codebases.
Different failure surfaces.
Same diagnostic shape:
Find where the system stopped preserving the truth another part depended on.
Then patch narrowly.
This is why I keep saying software drift is not only an AI-assisted-code problem.
AI makes drift faster and harder to ignore, but mature human-built systems drift too.
A package manager can drift across command/context boundaries.
A container tool can validate in the wrong phase.
A code generator can preserve the type but corrupt the emitted literal.
The surface changes.
The diagnostic question stays the same:
Which boundary stopped carrying the truth forward?
Public claim
The correct public claim for this field test is:
Scarab/SDS helped drive a bounded repair for OpenAPITools/openapi-generator#23550, where the Kotlin generator emitted OpenAPI 3.1 boolean const: true enum values as "true" strings even though the generated enum value type was kotlin.Boolean.
The upstream PR added narrow Kotlin generator handling so boolean enum values are emitted as Kotlin boolean literals, matching the existing primitive-handling pattern for types such as Int and Long.
The repair includes a focused toEnumValue assertion and a generated-output regression fixture.
The PR was accepted, added to the 7.24.0 milestone, and merged.
This does not claim to redesign OpenAPI 3.1 support or enum generation broadly. It fixes the boolean literal-emission boundary that produced uncompilable Kotlin.
Field Lab
Scarab Systems maintains a public Field Lab for selected diagnostic field tests.
The Field Lab publishes public case records from real open-source issues: the issue being examined, the suspected boundary, the evidence gathered, the validation performed, and the current status of the diagnostic claim.
Some cases may end with a local repair candidate.
Some may become upstream pull requests.
Some may remain diagnostic records only.
That status is part of the record.
Scarab Diagnostic Suite is proprietary, but the larger conversation is shared. Software drift is not one team’s problem, and AI-assisted development is making the need for better diagnostic framing more urgent across the industry.
If you know of a public open-source issue that looks like cross-layer drift, unclear ownership, software drift, AI-assisted code drift, phase confusion, or a boundary failure, you can suggest it as a Field Lab candidate.
Useful suggestions include the public issue link, the suspected boundary, reproduction notes if available, and why the issue may be diagnostically interesting.
The goal is simple:
Make the failure legible.
Find the boundary.
Preserve the evidence.
Repair narrowly.
Let the win trickle down.
Disclosure: This field report was prepared with AI-assisted editing from my own field-test notes, public issue and PR records, validation summary, and repair record. The technical claims and final wording were reviewed before publication.
Top comments (0)