Required fields are nullable in OpenAPI

Support
1

I have…

  • [ ] Checked the logs and have uploaded a log file and provided a link because I found something suspicious there. Please do not post the log file in the topic because very often something important is missing.

I’m submitting a…

  • [ ] Regression (a behavior that stopped working in a new release)
  • [x] Bug report
  • [ ] Performance issue
  • [ ] Documentation issue or request

Current behavior

The OpenAPI always marks all fields with “nullable: true”, even if the field is required.
It doesn’t matter, if the field was always there or added only after publishing the schema.

Expected behavior

The OpenAPI marks only non-required fields as nullable.

Minimal reproduction of the problem

  1. Create a schema
  2. Add some fields (some of them required, some of them optional)
  3. Download the OpenAPI
  4. See that all fields are nullable

Environment

  • [x] Self hosted with docker
  • [ ] Self hosted with IIS
  • [ ] Self hosted with other version
  • [ ] Cloud version

Version: 6.6.0.0

Browser:

  • [x] Chrome (desktop)
  • [ ] Chrome (Android)
  • [ ] Chrome (iOS)
  • [ ] Firefox
  • [x] Safari (desktop)
  • [ ] Safari (iOS)
  • [ ] IE
  • [ ] Edge

Others:

There was the same unexpected behavior (which was then solved) some months ago: [SOLVED] Required fields are nullable in the OpenAPI specification

2

Hi Pascal,

I am not sure about the other issue you mentioned, but in general it is by design.

A required field means that when you create a new content item it is required. This does not mean that the field is actually not null, because sometimes the validation is added AFTER the field is marked as required. Therefore you have no 100% guarantee.

You could argue, that it is better to have the required annotation because it makes your code easier. For example when you generate a typescript client, BUT some generated clients also validate the JSON when it is queried and then fail.

3

Yeah, that’s exactly what I meant.
I wanted to generate the typescript client automatically based on the OpenAPI spec.

Regarding your suggestion: it would be better to have type safety at compile time instead of encountering runtime errors.
Then I’ll have to think of something else.

Thanks for your fast response :blush:

4

Another solution would be to make the fields really required. E.g. when a field is required but not there it could be replaced with a default value:

  • String => ''
  • Number => 0
  • References => []
  • Assets => []
  • Component => ???
  • Components => []
  • JSON => {}
  • Boolean => false
  • Tags => []
  • DateTime => ???
  • Geolocation => North Pole? (0, 0)

But as you can see not all fields have a good default and even though they are technically not null or undefined anymore, you could get the error at another place, e.g. when you expect that an asset has at least one item or so.