Schema for callbacks incorrectly omits readOnly and includes writeOnly properties

[lukas-krecan]

If we use readOnly in a callback one would expect that the semantics would be reversed than on the API. For example, if I have a readOnly ID, in callback it should be present in the request (initiated by my system) and it should not be present in the response from the third-party system.

Additional context or thoughts

In OAS 3.1 readOnly and writeOnly have been removed from the spec and instead it defers to the JSON Schema spec which says:

If "readOnly" has a value of boolean true, it indicates that the value of the instance is managed exclusively by the owning authority, and attempts by an application to modify the value of this property are expected to be ignored or rejected by that owning authority.

[...]

If "writeOnly" has a value of boolean true, it indicates that the value is never present when the instance is retrieved from the owning authority. It can be present when sent to the owning authority to update or create the document (or the resource it represents), but it will not be included in any updated or newly created version of the instance.

Note the concept of an "owning authority" instead of the "request" and "response" wording used in OAS 3.0.

See the same issue in swagger-ui swagger-api/swagger-ui#6294

[Nialld]

I would like to second this request. We are using x-webhook to define our webhook payload definitions.

We have an entity which has a readonly ID field and this is being excluded from the payload when using an existing schema.

Would it be possible to include a setting show readonly and hide writeonly fields on x-webhook or flip the logic to show readonly and hide writeonly

[zzip]

I would also like to second this request.

After reading the last comment from Ron Ratovsky in this thread
it seems it's up to the tooling on how to implement the behaviour of readOnly and writeOnly and not the spec.

I think the current behaviour for not displaying properties with readOnly: true in a schema response (re)used by webhooks is not the logical implementation, and hence should be displayed.

Currently it's blocking us to reuse schemas.

[RomanHotsiy]

Thanks, guys for the report and for the useful context. I agree the current implementation is not logical.

We'll fix that.