adding a required property is showing as non-breaking

[Rico M]

No description provided.

[Sebastian Tello]

Hi @Rico M , it might be breaking or not depending on other factors that I can’t see in the attached image:

1. Is this schema being use in a request or a response?
2. Is additionalProperties set to anything in particular (it defaults to true).

I believe the case is this is a response schema and additionalProperties is not defined or set to true. Which means that consumers were before OK to receive values with any additional properties like foo or the newRequiredPropertyAdded of any type, and present or not. You just have made the domain of returned values more constraint but within the boundaries of what consumers already accepted.

To simplify: if supported values (for a response) used to be [1, 2, 3, 4, 5, 6] and now are [3, 4] .. nothing breaks, consumers already were accepting 3 and 4. However if you make the same change for a request schema, that would be breaking, consumers sticking to the old schema might be sending values like 1, or 6 which the provider no longer accepts.

‌

[Sebastian Tello]

waiting for reporter's feedback

[Rico M]

The schema is being used in the response. And I was getting these results:

‌

Then you mentioned about additionalProperties and I found out I had it set to false.

So I set the value to true and now I am getting this response

‌

So, should addiontalProperties set to true if I am adding properties in the response object schema?

However, I was adding but the code says remove. Any insights to that?

‌

[Rico M]

I also tried using the schema in a request, I am adding a new property in the request schema but the code says remove

‌

‌

[Rico M]

added my comments

[Rico M]

any news on this please?

[Sebastian Tello]

The output is correct @Rico M .. When you have additionalProperties: true and you “add” a new property, you are not actually adding, but constraining that property from being anything to a specific value. For example, this schema

{ 
   type: object,
   additionalProperties: true,
   properties: {
      one: {type: string}
   }
}

allows values like: {}, {one: "foo"}, {one: "foo", two: 2}, {one: "foo", two: "bar"} , {two: []}

Notice it does support any property with any type (only constraint is that is property “one” is present must be string. However if you “add” a property two:

{ 
   type: object,
   additionalProperties: true,
   properties: {
      one: {type: string},
      two: {type: number}
   }
}

you are not actually adding, two was already supported by the first schema, you are constraining the possible values to be only numbers. So, from the previous examples the following values are no longer supported: {one: "foo", two: "bar"}, {two: []}. That’s why the type of the change is remove, you are constraining the scope of possible values by being more specific about the shape of the response.

[Sebastian Tello]

working as expected