Closed
Description
Bug Report Checklist
- Have you provided a full/minimal spec to reproduce the issue?
- Have you validated the input using an OpenAPI validator (example)?
- Have you tested with the latest master to confirm the issue still exists?
- Have you searched for related issues/PRs?
- What's the actual output vs expected output?
- [Optional] Sponsorship to speed up the bug fix or feature request (example)
Description
When using the Elixir generator with model composition, the resulting type specifications can be both incorrect and invalid - leading to compilation errors in the generated Elixir client.
This issue manifests when an allOf
composition references only a single schema. In such cases, the generated typespec looks like the following:
@spec bar(Tesla.Env.client(), keyword()) :: {:ok, OpenAPI.Model.any().t()} | {:error, Tesla.Env.t()}
Notice the problematic OpenAPI.Model.any().t()
. This is not a valid Elixir type. At best, it should be any()
, but ideally, the generator should produce the actual schema module, such as OpenAPI.Model.Bar200Response.t()
.
This suggests there are two separate problems:
- Type name normalization is failing and not treating
any()
as a terminal type. - Schema resolution is not correctly identifying the intended model for the typespec.
openapi-generator version
7.12.0
OpenAPI declaration file content or url
openapi: 3.0.0
info:
version: 1.0.0
title: A minimal OpenAPI example
paths:
/foo:
get:
operationId: foo
responses:
200:
description: Successful operation
content:
application/json:
schema:
allOf:
- $ref: "#/components/schemas/Foo"
- $ref: "#/components/schemas/Bar"
/bar:
get:
operationId: bar
responses:
200:
description: Successful operation
content:
application/json:
schema:
allOf:
- $ref: "#/components/schemas/Foo"
components:
schemas:
Foo:
type: object
properties:
foo_value:
type: string
Bar:
type: object
properties:
bar_value:
type: string
Generation Details
openapi-generator-cli generate -i $(OAS_FILE) -g elixir -o local/out/elixir