DateOnly serialization doesn't play nice with GitHub's OpenAPI spec

[kfcampbell]

Hi Kiota people! This issue is the Kiota side of octokit/source-generator#23, in which the GitHub SDK team is using Kiota to generate Go code off of our (GitHub's) OpenAPI spec.

Specifically, we're seeing errors with DateOnly arrays as @baywet pointed out.

In the following code snippet,

// Get get all supported GitHub API versions.
// [API method documentation]
// 
// [API method documentation]: https://docs.github.com/rest/meta/meta#get-all-api-versions
func (m *VersionsRequestBuilder) Get(ctx context.Context, requestConfiguration *VersionsRequestBuilderGetRequestConfiguration)([]i878a80d2330e89d26896388a3f487eef27b0a0e6c010c493bf80be1452208f91.DateOnly, error) {
    requestInfo, err := m.ToGetRequestInformation(ctx, requestConfiguration);
    if err != nil {
        return nil, err
    }
    errorMapping := i2ae4187f7daee263371cb1c977df639813ab50ffa529013b7437480d1ec0158f.ErrorMappings {
        "404": i158396662f32fe591e8faa247af18558546841dba91f24f5c824e11e34188830.CreateBasicErrorFromDiscriminatorValue,
    }
    res, err := m.BaseRequestBuilder.RequestAdapter.SendCollection(ctx, requestInfo, i158396662f32fe591e8faa247af18558546841dba91f24f5c824e11e34188830.CreateKeySimpleFromDiscriminatorValue, errorMapping)
    if err != nil {
        return nil, err
    }
    val := make([]i878a80d2330e89d26896388a3f487eef27b0a0e6c010c493bf80be1452208f91.DateOnly, len(res))
     for i, v := range res {
         if v != nil {
             val[i] = *(v.(*i878a80d2330e89d26896388a3f487eef27b0a0e6c010c493bf80be1452208f91.DateOnly))
         }
    return val, nil
}

the cast al[i] = *(v.(*i878a80d2330e89d26896388a3f487eef27b0a0e6c010c493bf80be1452208f91.DateOnly)) will not compile, as Go complains that *serialization.DateOnly does not implement serialization.Parsable (missing method GetFieldDeserializers).

As noted in the code block, the docs endpoint for that request is here and our OpenAPI schema for it looks like:

"/versions": {
      "get": {
        "summary": "Get all API versions",
        "description": "Get all supported GitHub API versions.",
        "tags": [
          "meta"
        ],
        "operationId": "meta/get-all-versions",
        "externalDocs": {
          "description": "API method documentation",
          "url": "https://docs.github.com/rest/meta/meta#get-all-api-versions"
        },
        "responses": {
          "200": {
            "description": "Response",
            "content": {
              "application/json": {
                "schema": {
                  "type": "array",
                  "items": {
                    "type": "string",
                    "format": "date",
                    "example": "2021-01-01"
                  }
                },
                "examples": {
                  "default": {
                    "value": [
                      "2021-01-01",
                      "2021-06-01",
                      "2022-01-01"
                    ]
                  }
                }
              }
            }
          },
          "404": {
            "$ref": "#/components/responses/not_found"
          }
        },
        "x-github": {
          "githubCloudOnly": false,
          "enabledForGitHubApps": true,
          "category": "meta",
          "subcategory": "meta"
        }
      }
    },

Please let me know if we need to make schema changes, if we can help out on the Kiota side at all, or if I can provide more information!

[rkodev]

@baywet we can resolve this serialization by adding the date types introduced in the kiota-abstractions-go to be handled by SendPrimitiveCollection and SendPrimitive. i.e they are to be treated as "primitives" in kiota.

[baywet]

@rkodev thanks for joining the discussion. I think it was the plan all along (DateOnly, TimeOnly, DateTime, DateTimeOffset).
However, I don't believe it requires a change in the interface (abstractions) but simply a change in the generation logic, and maybe a change in the implementation to handle those types.
Thoughts?

[rkodev]

yes, we will not be changing the interface only implementing the missing types and modifying generation logic

[baywet]

great! please go ahead with the pull request