[DO_NOT_MERGE] chore: add support for OpenAPI 3.1 - #1280
Draft
afsinka-backbase wants to merge 5 commits into
Draft
[DO_NOT_MERGE] chore: add support for OpenAPI 3.1#1280afsinka-backbase wants to merge 5 commits into
afsinka-backbase wants to merge 5 commits into
Conversation
The dependency stack was already 3.1-capable (swagger-parser 2.1.46 detects
3.1 and sets OpenAPI.specVersion, swagger-core 2.2.54 ships Yaml31/Json31
with the 3.1 Jackson mixins), but nothing used it. A 3.1 spec parsed into a
model that knew it was 3.1 and was then written back out through the 3.0
mapper, yielding a document with an `openapi: 3.1.0` header and a
3.0-serialized body: `webhooks` dropped entirely, and `const`, type arrays
and `contentMediaType` flattened to `{}`. An invalid hybrid, with no warning.
Serialization:
- SerializerUtils.toYamlString now branches on the spec version, and gains
isOpenApi31, toJsonString and yamlMapper/jsonMapper accessors. Version
detection prefers getSpecVersion() and falls back to the `openapi` header,
because `new OpenAPI()` defaults to V30 and a document that lost its spec
version in an earlier round trip must still be recognised. This one change
covers the six mojos that already funnel through toYamlString.
- ExtensionFilter and DeduplicateSchemasTransformer round-tripped the whole
document through the 3.0 mapper, losing 3.1 keywords in memory; they now
use the version-appropriate mapper. ExtensionFilter also restores
specVersion, since treeToValue builds a fresh OpenAPI defaulting to V30.
- GenerateMojo's three debug dumps went straight to Yaml.pretty, bypassing
SerializerUtils; they now go through it.
Linting:
- OpenApiVersionRule (M0012) matched an exact allowlist. It now also accepts
configured regex patterns, so boat.conf and the test reference.conf allow
every 3.1 patch release without enumerating them. The config key is read
via hasPath, as getStringList throws on a missing path and consumers may
supply a boat.conf predating the key.
- Zally's rule 219 validates every OpenAPI 3 document against the OAS 3.0
JSON schema and cannot be pointed at two schemas at once, so on a 3.1
document every violation it reports is a false positive. BoatLinter now
drops those, reusing the parse it already performed.
- The (unreferenced) Spectral ruleset is anchored to ^3\.(0\.[34]|1\.\d+)$.
This also aligns 3.0 with boat.conf, which has allowed 3.0.4 all along.
Tests add the first 3.1 fixtures in the repo, covering webhooks, type
arrays, const, numeric exclusiveMinimum and contentMediaType, and were each
checked to fail without their fix.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The accepted OpenAPI versions were a 3.0 allowlist plus a configurable regex pattern list that matched the whole 3.1 line. Enumerating the three released 3.1 versions instead keeps the rule's original semantics -- exact membership of one configured list -- so OpenApiVersionRule needs no logic of its own and reverts to being byte-identical to the version before 3.1 support was added. A new 3.1 patch release now requires a one-line config change, which is the same maintenance already accepted for the 3.0 versions. The Spectral ruleset is narrowed to match. Its `pattern` function only takes a regex, so that stays one, but bounded to the same five versions rather than open-ended. The rule test gains 3.1.3 as a negative case to pin the boundary: it confirms the allowed versions are an explicit list rather than the whole 3.1 line, and that such a version reaches the rule at all rather than being rejected earlier by swagger-parser, which accepts any 3.1.x prefix. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
afsinka-backbase
requested review from
bartveenstra,
bbzurek,
dhananjay12 and
jjjasper
August 28, 2026 12:29
SerializerUtils.isOpenApi31 and yamlMapper accept a null document by design, which makes Sonar's dataflow analysis carry a "may be null" state into their callers and report S2259 on later dereferences of documents that are in fact never null. Make the non-null contract explicit at both call sites instead of loosening the null-tolerant helpers, which ValidateMojo relies on. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
N.B. I'm not familiar with BOAT repo so please review it carefully