allof-conflicts

allOf is an intersection. When the same property is defined across allOf branches with incompatible types, the composed schema has no common valid type for that property.

This rule detects those conflicting property definitions and reports the composed schema as invalid.

Why did this violation appear?

Your schema combines multiple object schemas with allOf, and the same property name appears more than once with incompatible type constraints.

For example, if one branch defines kind as a string and another defines kind as a number, then any instance containing kind would need to be both a string and a number at the same time.

What is this rule checking for?

The rule walks the fully composed schema graph for OpenAPI 3.x documents and checks:

• properties defined directly on the composed schema
• properties defined on schemas referenced from allOf
• nested allOf compositions
• circular allOf references

It reports a violation when the same property is constrained by multiple typed definitions whose common valid type set is empty.

Bad example

components:
  schemas:
    Base:
      type: object
      properties:
        name:
          type: string
        kind:
          type: string

    Conflict:
      type: object
      allOf:
        - $ref: "#/components/schemas/Base"
        - type: object
          properties:
            kind:
              type: number

Good example

components:
  schemas:
    Base:
      type: object
      properties:
        name:
          type: string
        kind:
          type: string

    Compatible:
      type: object
      allOf:
        - $ref: "#/components/schemas/Base"
        - type: object
          properties:
            kind:
              type: string

How do I fix this violation?

Make sure every repeated property in the allOf composition is compatible across all branches:

• Use the same property type everywhere the property appears
• Remove the duplicate property definition if the base definition is already correct
• Redesign the schema if the branches represent alternatives rather than an intersection

If the branches are intended to be alternatives, oneOf or anyOf is often a better fit than allOf.