request-parameter-property-type-changed
Request parameter property type changed.
directionrequestareaparameterskindtypeactionchange
Potentially breaking (level: warning)
Whether this breaks a client depends on how the client is built and whether the server validates requests, so oasdiff surfaces it for review rather than failing the build.
How to handle this change
When oasdiff flags request-parameter-property-type-changed, you have a few ways to respond:
- Find a backward-compatible alternative. Redesign the change so clients that followed the old contract keep working, and agree on the approach with whoever introduced it.
- Release it in a new API version. Keep the current contract and introduce the change in a new version, then deprecate the old one with a sunset date so clients have time to migrate.
- Accept it as a deliberate breaking change. Sometimes a breaking change is unavoidable, such as an urgent or security fix. Approve it knowingly, document it in your release notes, and tell affected clients. This should be the exception, not a routine way of working.
If oasdiff's verdict does not match your API's compatibility policy, you can also change how it treats request-parameter-property-type-changed with a severity-levels file:
Put one rule per line; the level can be err, warn, or info, or none to disable the check entirely:
# severity.txt
request-parameter-property-type-changed errThen pass it to oasdiff:
oasdiff changelog base.yaml revision.yaml --severity-levels severity.txtRelated parameters rules
- new-optional-request-default-parameter-to-existing-path
- new-optional-request-parameter
- new-request-path-parameter
- new-required-request-default-parameter-to-existing-path
- new-required-request-header-property
- new-required-request-parameter
- request-header-property-became-enum
- request-header-property-became-required