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?
Hard to tell
Description
openapi-generator version
OpenAPI declaration file content or url
openapi: 3.0.3
info:
title: Clean Architecture Api Specification
description: Clean Architecture Api Specification
version: 1.0.1
servers:
- url: 'https://localhost:5000'
description: Local Development Server
paths:
/ToDoItems:
put:
operationId: ToDoItem.Update
description: Updates a ToDoItem
tags:
- TodoItemEndpoints
requestBody:
content:
multipart/form-data:
schema:
type: object
properties:
orderId:
type: integer
updatedRequest:
$ref: '#/components/schemas/UpdateToDoItemRequest'
responses:
200:
description: The updated ToDo Item
content:
application/json:
schema:
$ref: '#/components/schemas/ToDoItemResponse'
components:
schemas:
UpdateToDoItemRequest:
type: object
properties:
Id:
type: integer
Title:
type: string
Description:
type: string
ToDoItemResponse:
type: object
properties:
Id:
type: integer
Title:
type: string
Description:
type: string
IsDone:
type: boolean
Generation Details
Generate a csharp client or aspnetcore server with this spec and see that it fails to compile, reason being that the method signatures contians models which are not generated by default for form parameter model classes
Suggest a fix
Generate models by default for those generators, or flatten method signatures by default.
Discussion Start Point
Apparently the default right now is to not generate model classes for objects which are referenced in multipart/form-data sections. This was apparently done after people migrating from openapi 2 complained. This however results in those cases producing non compiling code for csharp, might as well for other languages, didn't try that.
I think producing non-compiling code in a default configuration for any apispec is not a good thing. The goal should be that whatever the spec the default configuration always results in valid code