I am using the OpenAPI specification provided by OpenZiti for the OpenZiti Controller. It appears that the OpenAPI spec is not aligned with the actual behavior of the OpenZiti Controller. Specifically, the roles attribute defined under .definitions.roles in the OpenAPI spec is not marked as nullable.
However, the OpenZiti Controllers' API returns null for the roles property (e.g. EdgeRouterPolicyDetail Model, specifically properties edge_router_roles & identity_roles) when querying router or service policies that do not have roles attached.
This discrepancy leads to an issue in my autogenerated client implementation (based on the OpenAPI spec), as the code attempts to validate the model data returned by the OpenZiti Controller. The returned object contains a null value for the roles attribute, causing validation errors.
I have also created an issue entry in the respective github repository.
thanks for reporting. Catching all the nullables are always a challenge. @andrew.martinez - can you have a peek at this and confirm/fix the issue? Thanks
Thanks for the report; it is a bug. Most of our tooling that uses the API is Go and Go treats null as an empty slice for most interactions (iteration, length), so these pop up from time to time.
Hi @andrew.martinez,
it seems like I have just at this moment discovered another case of the exact same issue.
I created a new router in the ZAC and then queried the list of routers on the management API by calling list_routers. Unfortunately this call has returned a RouterDetail object which has a value of null for the fingerprint property. This leads to another validation error in the generated API client, mentioned afore.
After checking the openapi spec for the management API I can see that the x-nullable: true options seems to be missing as in the other case.
Edit:
Was now testing to call list_routers vs. list_edge_routers and the issue only seems to appear when calling list_routers.