Certain fields should be marked 'nullable' in OpenAPI specification

[Integralist]

Related to an issue originally reported here:
#88 (comment)

We need to update Fastly's internal OpenAPI schemas to address instances where fields are missing nullable: true.

[jimr6007]

can you confirm that I'm likely having the same issue.

I've tried setting those params directly with vars versus the dict I have in the following example
tried casting to an int etc.

Thanks !

from fastly.api import diff_api
from fastly.model.diff_response import DiffResponse
with fastly.ApiClient(configuration) as api_client:
    api_instance = diff_api.DiffApi(api_client)
    options = {
      "service_id": "Z9rrXgB4RF6wJ6J8xwJVA7",
      "from_version_id": 1,
      "to_version_id": 2,
      "format": "text"
    }

    try:
        api_response = api_instance.diff_service_versions(**options)
    except fastly.ApiException as e:
        print("Exception when calling Fastly API: %s\n" % e)
    print(api_response)

and the error...
not sure where this var is coming from:
"Invalid type for variable '_from'."

File "/home/jrichard/fastly-hacking/fastly-venv/lib/python3.9/site-packages/fastly/model_utils.py", line 1448, in attempt_convert_item
    raise get_type_error(input_value, path_to_item, valid_classes,
fastly.exceptions.ApiTypeError: Invalid type for variable '_from'. Required value type is int and passed type was str at ['received_data']['_from']

[Integralist]

Hi @jimr6007 👋🏻

Typically an error like Required value type is int and passed type was str does suggest to me a field in Fastly's internal OpenAPI schema (used to generate this and other API clients) is incorrectly defined.

I didn't initially recognise the _from field, as I didn't see any such field defined by our OpenAPI schemas but looking at the API this call maps to (https://developer.fastly.com/reference/api/utils/diff/) I do see a from field, and that's when I noticed _from in the generated client code (here).

I think the client generation code has renamed the field to _from to avoid some kind of naming conflict.

I'm going to reach out to the relevant Fastly team to see if this particular field is supposed to be an int or a string (as we've had issues with this in the past).