Target: OpenAPITools/openapi-generator
Issue: OpenAPITools/openapi-generator#23920
PR: OpenAPITools/openapi-generator#24023
This field test targeted a Rust server generator bug in OpenAPI Generator where rust-server client-only builds could miss dependencies required by generated shared model code.
The visible issue was not that the Rust generator could not generate a client.
It was more specific:
- a rust-server project was generated
- the build was run with default features disabled
- the client feature was enabled
- generated shared model code could still emit pattern validation
- that pattern validation could require lazy_static and regex
- but the client-only feature path did not reliably wire those dependencies in
- the resulting Rust sample could fail under cargo check --no-default-features --features client
That is a classic generated-code boundary bug.
The user is not hand-writing the missing dependency usage.
The generator emits code that can require those crates.
So the generator also has to emit Cargo feature wiring that makes the generated code build under the feature combinations the generator claims to support.
The diagnostic question was not:
How do we make every Rust server feature depend on everything?
The better question was:
Which generated-code path can emit lazy_static and regex, and which Cargo feature boundary needs to own those dependencies?
Field Lab record
The public case record for this field test is available in the Scarab Field Lab:
Upstream posture
This was a clean upstream repair candidate.
The issue was open, the failure was reproducible in a narrow feature configuration, and the repair surface was inside OpenAPI Generator’s owned Rust server template and sample-generation path.
That matters because this was not a dependency wish-list patch.
It was a generator correctness patch.
When a generator emits code behind a supported feature combination, the generated Cargo manifest has to include the dependencies required by that code path.
The upstream PR was opened cleanly and contains no SDS, Scarab, Codex, local-path, or internal workflow language.
SDS result
This field test was run in SDS field-test posture against a disposable OpenAPI Generator arena.
The useful result was a bounded ownership read.
The failure lived across a small but important chain:
- OpenAPI schema input
- generated Rust shared model code
- pattern-validation output
- Cargo dependency and feature wiring
- client-only Rust sample compilation
That chain points to a generator-owned boundary.
The correct repair was not to remove validation.
It was not to tell users to manually add crates.
It was not to make every generated build pull every dependency all the time.
It was to tighten the rust-server Cargo feature wiring so a client-only build includes the dependencies required by generated shared models when those models emit pattern validation code.
Failure shape
The failure shape was a feature/dependency mismatch.
The generated Rust code could require lazy_static and regex.
The client-only build path could still compile shared models.
But the Cargo feature wiring did not reliably include the crates needed by that shared generated code.
That creates a broken generated project because the feature combination is internally inconsistent.
In plain English:
the generator emitted code that needed crates the selected feature path did not provide
That is not a Rust compiler problem.
That is not a user application problem.
That is not a case where the user forgot to add a dependency by hand.
It is a generator contract problem.
If the generated code can reference a crate under a supported feature build, the generated manifest has to make that crate available under that same feature build.
Boundary
The boundary here is:
generated shared model requirements versus generated Cargo feature wiring
OpenAPI Generator owns both sides of that boundary.
It owns the generated Rust model code.
It owns the generated Cargo manifest template.
So when shared models can emit pattern validation using lazy_static and regex, the feature path that compiles those models has to carry the matching dependency wiring.
That is the repair surface.
The patch does not redesign Rust server generation.
It does not remove model validation.
It does not flatten every Cargo feature into one broad dependency set.
It tightens the feature wiring around the actual generated-code requirement.
That is the Scarab boundary:
when generated code and generated build metadata disagree, repair the smallest owned seam where the contract breaks
What changed
The PR tightens rust-server Cargo feature wiring so client-only builds include the dependencies needed by generated shared model validation code.
The specific dependency path involved lazy_static and regex, which can be required when generated shared models emit pattern validation logic.
The patch adds a focused regression fixture and test for the feature combination.
It also regenerates the affected Rust server samples so the checked-in generated output reflects the corrected template behavior.
That matters because this is a generator project.
A fix is not complete if only the template changes.
The generated samples also need to show the corrected output, and the regression test needs to prove the feature combination remains buildable.
Why this was not a broad dependency patch
The tempting fix would be to make the generated Rust server manifest include more dependencies everywhere.
That would be easier, but it would be less precise.
The bug was not:
Rust server generation needs every dependency in every mode
The bug was:
a client-only feature build can still compile shared generated model code that requires lazy_static and regex
So the repair stayed near the feature boundary.
That is important because Cargo feature design is part of the generated project contract.
Over-wiring dependencies can hide the bug, but it also makes the generated output less disciplined.
The better repair is to make the feature path honest:
if the client feature can compile shared model validation code, then the client feature must carry the dependencies that validation code requires.
Why the diagnostic result mattered
This case is useful because it is another small patch with a real platform implication.
The failure is not visually dramatic.
There is no UI break.
There is no large subsystem rewrite.
But for anyone relying on generated Rust output, a broken client-only feature build is a real failure.
Generated code is often dropped into CI pipelines, SDK builds, integration tests, and downstream application work. If the generator emits a project that fails under one of its own supported feature combinations, the downstream user loses trust in the generator.
The value of the diagnostic posture was keeping the repair framed around the actual contract:
- OpenAPI Generator emits the model code.
- OpenAPI Generator emits the Cargo feature wiring.
- The selected feature combination must satisfy the code the generator emits.
- The repair should live where generated code requirements meet generated build metadata.
That framing kept the patch small.
It avoided a broad Rust server rewrite.
It avoided a user-side workaround.
It repaired the generator-owned seam.
Validation
The patch was validated with both focused and full project checks.
Validation passed for:
- targeted regression test
- Rust sample check with cargo check --no-default-features --features client
- full ./mvnw clean package
- full sample generation across 769 generators
- ./bin/utils/export_docs_generators.sh
- git diff --check
At the time of this report, the PR is open, ready for review, and mergeable.
CircleCI nodes are green.
Cubic AI review is green.
For the full validation record and public status, see the Field Lab case record:
Field test result
This was a bounded Rust server feature-wiring repair candidate for OpenAPI Generator.
The issue reduced to:
- rust-server client-only builds could compile generated shared models
- generated shared models could emit pattern validation code
- that validation code could require lazy_static and regex
- the client feature path did not reliably provide those dependencies
- the generated Rust project could fail under cargo check --no-default-features --features client
- the repair tightened Cargo feature wiring for the owned generated-code path
- a focused regression fixture/test was added
- affected Rust server samples were regenerated
- full validation passed
That is the repair lane.
This patch does not claim to redesign Rust server generation.
It does not claim to change OpenAPI validation semantics.
It does not claim that every generated feature should carry every dependency.
It fixes the feature boundary where generated shared model code and generated Cargo metadata stopped agreeing.
Public claim
The correct claim for this field test is:
Scarab/SDS helped drive a bounded repair candidate for OpenAPITools/openapi-generator#23920, where rust-server client-only builds could miss lazy_static and regex even though generated shared model code could emit pattern validation requiring those crates. The upstream PR tightens the Rust server Cargo feature wiring, adds a focused regression fixture/test, and regenerates affected Rust server samples. Validation passed through the targeted regression, cargo check --no-default-features --features client, full Maven package build, full sample generation across 769 generators, generator docs export, and whitespace checks. This does not claim to redesign Rust server generation or Cargo feature policy broadly; it fixes the generated-code/build-metadata boundary where the client feature path failed to carry dependencies required by generated shared model validation.
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)