[BUG] Inconsistent Discriminator Mapping in OpenAPI Schema

[SzymonZasada]

Problem Description

The OpenAPI specification contains duplicate schema definitions with inconsistent discriminator mappings, causing code generation failures.

Issue Details

Two schemas define the same structure with different discriminator mappings:

Schema 1: CompatibilityList

discriminator:
  propertyName: type
  mapping:
    MANUAL: '#/components/schemas/CompatibilityListManual'
    PRODUCT_BASED: '#/components/schemas/CompatibilityListProductBased'

Schema 2: CompatibilityListProductOfferResponse

discriminator:
  propertyName: type
  mapping:
    MANUAL: '#/components/schemas/CompatibilityListManual'
    PRODUCT_BASED: '#/components/schemas/CompatibilityListProductBasedProductOfferResponse'

Root Cause

• CompatibilityListProductOfferResponse maps to CompatibilityListProductBasedProductOfferResponse (does not exist as a distinct schema)
• CompatibilityList maps to CompatibilityListProductBased (correct)
• Generated code receives inconsistent type information, causing deserialization failures

Error When Using This Schema

InvalidTypeIdException: Could not resolve type id 'PRODUCT_BASED' as a subtype of CompatibilityListProductOfferResponse

Expected Behavior

Both schemas should use identical discriminator mappings OR one should be removed as redundant.

Suggested Fix

Remove CompatibilityListProductOfferResponse or make discriminator mappings consistent across all schemas that use type discrimination.

Impact

• Code generation tools (OpenAPI Generator, Swagger Codegen) produce non-functional classes
• Deserialization fails at runtime when API returns polymorphic types
• Multiple similar issues throughout the specification

Example
CompatibilityList: type: object properties: type: type: string default: 'MANUAL' example: 'MANUAL' description: 'Type of the compatibility list, two values are acceptable:MANUAL, PRODUCT_BASED. <ul> <li>MANUAL - for offers not associated with product - compatibility list is created with items provided by user directly in the body of the request.</li> <li>PRODUCT_BASED- for offers associated with product - if compatibility list is provided in the product details (GET/sale/products/{productId}), it needs to be included in the offer in unchanged form. </li> </ul>' required: - type discriminator: propertyName: type mapping: MANUAL: '#/components/schemas/CompatibilityListManual' PRODUCT_BASED: '#/components/schemas/CompatibilityListProductBased' CompatibilityListProductOfferResponse: type: object properties: type: type: string default: 'MANUAL' example: 'MANUAL' description: 'Type of the compatibility list, two values are acceptable:MANUAL, PRODUCT_BASED. <ul> <li>MANUAL - for offers not associated with product - compatibility list is created with items provided by user directly in the body of the request.</li> <li>PRODUCT_BASED- for offers associated with product - if compatibility list is provided in the product details (GET/sale/products/{productId}), it needs to be included in the offer in unchanged form. </li> </ul>' required: - type discriminator: propertyName: type mapping: MANUAL: '#/components/schemas/CompatibilityListManual' PRODUCT_BASED: '#/components/schemas/CompatibilityListProductBasedProductOfferResponse' CompatibilityListManual: allOf: - $ref: '#/components/schemas/CompatibilityList' - $ref: '#/components/schemas/CompatibilityListManualType' CompatibilityListManualType: type: object required: - items properties: items: type: array items: $ref: '#/components/schemas/CompatibilityListItem' description: 'List of the compatible items. Maximum number of elements on the list depends on type of included compatible items. Configuration and details concerning the compatible items in selected category are provided in the response for GET <a href="/documentation/#tag/Compatibility-List/paths/~1sale~1compatibility-list~1supported-categories/get"> supported-categories</a> resource invalidationRules object.'