[Bug]: `ResolverFully` does not process OAS 3.1 combinators and skips nested OAS 3.1 schema-valued keywords

[ib-fsrnec]

Description

When resolveFully and resolveCombinators are enabled, ResolverFully merges allOf/oneOf/anyOf for OpenAPI 3.0 documents, but does not process them for OpenAPI 3.1 documents.

The same schema is deserialized differently between the two versions: OAS 3.0 uses specific classes such as ComposedSchema, while OAS 3.1 uses JsonSchema. The current resolver checks for these OAS 3.0 subclasses, so OAS 3.1 combinators are silently skipped.

The same issue affects recursive resolution of schema-valued OAS 3.1 keywords such as items, additionalProperties, prefixItems, contains, propertyNames, if/then/else, and dependentSchemas.

PR: #2404.

Affected Version

Confirmed in: 2.1.48 (latest version)

Earliest version the bug appears in (if known): present since OpenAPI 3.1 full resolution was introduced.

Steps to Reproduce

1. Create an OpenAPI 3.1 document containing an allOf schema:

openapi: 3.1.0
info:
  title: ResolverFully reproduction
  version: 1.0.0
paths:
  /example:
    post:
      requestBody:
        content:
          application/json:
            schema:
              type: object
              allOf:
                - type: object
                  properties:
                    first:
                      type: string
                - type: object
                  properties:
                    second:
                      type: string
      responses:
        '200':
          description: OK

2. Parse it with the following options:

ParseOptions options = new ParseOptions();
options.setResolve(true);
options.setResolveFully(true);
options.setResolveCombinators(true);

OpenAPI openAPI = new OpenAPIV3Parser()
        .readContents(yaml, null, options)
        .getOpenAPI();

3. Inspect the request-body schema:

Schema schema = openAPI.getPaths().get("/example").getPost()
        .getRequestBody().getContent().get("application/json").getSchema();

Regression coverage for this behavior is available in ResolveCombinatorsOas31Test.

Expected Behavior

For OpenAPI 3.1, the schema should be handled consistently with the equivalent OpenAPI 3.0 document when resolveCombinators is enabled.

Schema-valued keywords nested inside an OAS 3.1 JsonSchema should also be recursively resolved.

Actual Behavior

For OpenAPI 3.1, the returned schema retains its allOf array and does not expose the merged properties.
No warning or error is produced, the parse result messages remain empty. The equivalent OpenAPI 3.0 document is merged as expected.

Logs / Stack Traces

No exception is thrown and no stack trace is produced. SwaggerParseResult.getMessages() is empty.

Environment

All environments. The issue is in the code itself.

Additional Context

The root cause is the instanceof ComposedSchema, ArraySchema, and MapSchema checks in ResolverFully.resolveSchemaImpl. These checks match OAS 3.0 deserialization but do not match OAS 3.1 JsonSchema instances. The relevant combinator getters and schema-valued keyword getters are available on the base Schema class.

A minimal fix would process combinators through the base Schema getters and add an OAS 3.1 traversal path for schema-valued keywords without returning early, because one OAS 3.1 schema may contain multiple keyword groups at the same time.

There is a known limitation in the existing combinator aggregation behavior: flattening arbitrary combinators into a new schema is not fully lossless and may drop sibling constraints or alter oneOf/anyOf semantics. A complete solution may require preserving the combinator structure or performing schema intersection. This should be tracked separately from the traversal fix.

The current deserializer also stores parsed additionalItems as an extension instead of populating Schema.additionalItems; that is a separate deserialization issue.

Checklist

• I have searched the existing issues and this is not a duplicate.
• I have provided sufficient information for maintainers to reproduce the issue.