Issue resolving referenced schema objects under `allOf`

[Jon Lunsford]

I'm attempting to generate a client using this corrected version of the official Spotify API Spec.

I noticed that a few schemas are failing to reference schemas that are under allOf keys where a $ref is at the root, like this:

AlbumObject:
  type: object
  allOf:
    - $ref: "#/components/schemas/AlbumBase" # <- I think this is causing an issue?
    - type: object
      properties:
        artists:
          type: array
          items:
            $ref: "#/components/schemas/SimplifiedArtistObject"
          description: |
            The artists of the album. Each artist object includes a link in `href` to more detailed information about the artist.

I'd expect the AlbumBase schema (reference) to be merged into the properties map of the parent AlbumObject, but this is the resulting struct:

defmodule Spotify.AlbumObject do
  @moduledoc """
  Provides struct and type for a AlbumObject
  """

  @type t :: %__MODULE__{}

  defstruct []

  @doc false
  @spec __fields__(atom) :: keyword
  def __fields__(type \\ :t)

  def __fields__(:t) do
    []
  end
end

For reference, here's the config I'm using:

config :oapi_generator,
  default: [
    output: [
      base_module: Spotify,
      location: "lib/",
      operation_subdirectory: "operations/",
      schema_subdirectory: "schemas/"
    ]
  ]

For debugging, I've paired down the full spec file to just this AlbumObject, and associated schemas, in this gist.

Any ideas? The spec itself appears to be technically valid.

[AJ Foster]

Hi @jonlunsford, great catch. allOf is a difficult key to handle, because we basically need to create a new schema with the combined fields. The generator doesn't do this right now, simply because I hadn't figured out a nice, clean way to do it.

We need a create_intersection helper similar to the create_union function that already exists in type.ex. As you expected, it needs to merge the available fields into a new schema spec and save it for rendering later.

[Jon Lunsford]

Thanks for the info @aj-foster, I was curious if this use case was covered or not. Is this something that is on your roadmap already? I'd like to contribute, but I'll admit the amount of complexity to grok here will take me some time to get up to speed and I wouldn't wan't to duplicate efforts.

[AJ Foster]

Thank you for the reduced test case. It made it very easy to try out a potential fix, which is now in #36. When you have a chance, could you look over the output code and see if has what you expect?

I will need to consider the PR a bit further to make sure it isn't breaking other use-cases, but I'm optimistic about the initial results!

[Jon Lunsford]

Amazing, I tested #36 locally with the full open api spec and every single schema rendered properly!

[AJ Foster]

Hello again 👋🏼

Release 0.1.0-rc.4 has changes to help with this. If you have a chance, please try it out and let me know how it works for you.

[Jon Lunsford]

Thanks @aj-foster , I will take a look at the latest release!