Skip to content

Treat new PUT request properties as compatible again #538

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jul 25, 2023
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Next Next commit
Treat new PUT request properties as compatible.
Effectively reverts change for #136 which appears invalid in intent, implementation, and test.
- Invalid in intent: #136 claims that adding a readOnly property to the request body of a PUT request is a breaking change because clients will begin to omit it and the server will interpret the omission as a directive to delete the property. This is incorrect because the server should expect, [per the OAS spec](https://spec.openapis.org/oas/v3.0.3#fixed-fields-19), that readOnly properties "SHOULD NOT be sent as part of the request". So it would be a bug for the server to delete any data associated with the readOnly property. Regardless, the API is left unbroken if the server simply ignores readOnly properties.
- Invalid in implementation: the code treats as incompatible any PUT request property, not just readOnly properties.
- Invalid in test: no readOnly properties are tested.

In theory one could argue that some servers might enforce the "SHOULD NOT" language of the spec by returning validation errors where they didn't before, and this would constitute an API breakage. But that should be discussed in a different issue.
  • Loading branch information
westse committed Jul 21, 2023
commit be914cb14fdeaa1de9f1707d9bd98731d588e0f7
Original file line number Diff line number Diff line change
@@ -1,6 +1,5 @@
package org.openapitools.openapidiff.core.model;

import io.swagger.v3.oas.models.PathItem;
import io.swagger.v3.oas.models.media.Schema;
import java.util.*;
import java.util.stream.Collectors;
Expand Down Expand Up @@ -157,9 +156,6 @@ private DiffResult calculateCoreChanged() {
}

private boolean compatibleForRequest() {
if (PathItem.HttpMethod.PUT.equals(context.getMethod()) && !increasedProperties.isEmpty()) {
return false;
}
return (oldSchema != null || newSchema == null);
}

Expand Down
Original file line number Diff line number Diff line change
@@ -1,9 +1,10 @@
package org.openapitools.openapidiff.core;

import static org.assertj.core.api.Assertions.assertThat;
import static org.openapitools.openapidiff.core.TestUtils.assertOpenApiAreEquals;
import static org.openapitools.openapidiff.core.TestUtils.assertOpenApiBackwardIncompatible;

import org.junit.jupiter.api.Test;
import org.openapitools.openapidiff.core.model.ChangedOpenApi;

public class AddPropPutDiffTest {
private final String OPENAPI_DOC1 = "add-prop-put-1.yaml";
Expand All @@ -15,7 +16,9 @@ public void testDiffSame() {
}

@Test
public void testDiffDifferent() {
Copy link

@mas-chen mas-chen Jul 20, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should remove this test. In fact it should be kept to check that the two docs are indeed compatible.

So we should have a testFieldAdditionalInPutApiIsCompatible or something similar

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mas-chen Good point about not losing a test. I think my #546 PR will address this.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's better to keep changes isolated. Since this PR is introducing a new fix, that particular test should be included here, to validate your change

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough. I've made your suggested changes. Look ok?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me but I'm not a contributor, would be good to get the help of one to merge this fix

assertOpenApiBackwardIncompatible(OPENAPI_DOC1, OPENAPI_DOC2);
public void testFieldAdditionalInPutApiIsCompatible() {
ChangedOpenApi changedOpenApi = OpenApiCompare.fromLocations(OPENAPI_DOC1, OPENAPI_DOC2);
assertThat(changedOpenApi.isDifferent()).isTrue();
assertThat(changedOpenApi.isCompatible()).isTrue();
}
}