Description
Schemas combined with allOf apply every branch’s constraints; later definitions do not overwrite earlier ones. Repeating a property name is allowed, but if one branch requires an integer and another requires a string, a value for that property cannot satisfy both.
Potential impact
Data containing the property may fail validation, or documentation and generated models may misrepresent the combined constraints. If the property is optional, an object without it may still be valid.
Remediation
Review all types and constraints applied to the same property and resolve conflicts according to the actual contract. Retain valid allOf combinations that add compatible constraints; do not rename a property merely because its name repeats.
Examples
These OpenAPI 3.0 schema excerpts omit info and paths. The first requires any code value to be both an integer and a string, which is impossible. The property itself is not required.
Before
{
"openapi": "3.0.0",
"components": {
"schemas": {
"ErrorModel": {
"type": "object",
"properties": {
"code": {
"type": "integer"
}
},
"allOf": [
{
"type": "object",
"properties": {
"code": {
"type": "string"
}
}
}
]
}
}
}
}
After
{
"openapi": "3.0.0",
"components": {
"schemas": {
"ErrorModel": {
"type": "object",
"properties": {
"code": {
"type": "integer"
},
"rootCause": {
"type": "string"
}
}
}
}
}
}
The second defines integer code and string rootCause separately. This suits a contract that actually needs both fields; splitting names is not a mandatory fix for all repeated constraints.