Fix Host OpenApi spec

[balanza]

cluster_id is, in fact, nullable for hosts, as they do not always belong to a cluster.

[Copilot]

Pull Request Overview

This PR updates the Host OpenAPI schema to allow cluster_id to be nullable and adds a test to ensure the hosts endpoint handles null cluster_id values correctly.

• Mark cluster_id as nullable in the OpenAPI schema
• Add controller test for hosts response when cluster_id is null

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
test/trento_web/controllers/v1/host_controller_test.exs	Added test case to verify handling of null cluster_id
lib/trento_web/openapi/v1/schema/host.ex	Marked cluster_id field as nullable: true in schema

Comments suppressed due to low confidence (2)

test/trento_web/controllers/v1/host_controller_test.exs:38

• Consider adding an explicit assertion to verify that the returned host’s cluster_id is null in the JSON response, for example:

response = get(conn, "/api/v1/hosts") |> json_response(200)
assert Enum.all(response["data"], fn host -> host["cluster_id"] == nil end)

      |> json_response(200)

lib/trento_web/openapi/v1/schema/host.ex:105

• [nitpick] It may be helpful to update the description to mention that cluster_id can be null (e.g., "Identifier of the cluster this host is part of, or null if it does not belong to a cluster") to make the API contract clearer for consumers.

            description: "Identifier of the cluster this host is part of",

[nelsonkopliku]

Good catch!

[gagandeepb]

An additional caveat is that that we should not rely too much on nullability via OpenAPI. The reason is that there is no support for explicitly nullable fields in OpenAPI version 3.1. (It should be fine for now since we are on a version of the spec that is < 3.1 that has support for nullability and the library we use has limited/probably no upgrade path to spec version 3.1.)

[balanza]

An additional caveat is that that we should not rely too much on nullability via OpenAPI. The reason is that there is no support for explicitly nullable fields in OpenAPI version 3.1. (It should be fine for now since we are on a version of the spec that is < 3.1 that has support for nullability and the library we use has limited/probably no upgrade path to spec version 3.1.)

Should we go for [string, null] instead? cannot do it

[gagandeepb]

@balanza It is fine as it is for now. There are other places where we use the explicit nullability that will need to get refactored too if/when we upgrade to spec version 3.1.