[Task]: OpenAPI Spec: Duplicate Model Name Conflict

[lukehinds]

Description

I encountered an issue while trying to generate a client library from the api/openapi.json specification using the openapi-python-client tool (and likely other OpenAPI generators).

Problem:

The generator fails because it attempts to create duplicate model names. This seems to stem from the naming convention where schemas exist both with and without an -Output suffix, but normalize to the same name during generation.

Specifically, the following pairs cause conflicts:

• #/components/schemas/FullWorkspace and #/components/schemas/FullWorkspace-Output both seem to normalize to FullWorkspace.
• #/components/schemas/WorkspaceConfig and #/components/schemas/WorkspaceConfig-Output both seem to normalize to WorkspaceConfig.

Impact:
This naming collision prevents the generator from creating the necessary models, resulting in warnings and errors like:

WARNING parsing POST /api/v1/workspaces within code_gate_api.
Cannot parse response for status code 201 (Could not find reference in parsed models or enums), response will be omitted from generated client
Reference(ref='#/components/schemas/FullWorkspace-Output')
...
Unable to parse schema /components/schemas/FullWorkspace-Output
Unable to parse this part of your OpenAPI document: : Attempted to generate duplicate models with name "FullWorkspace"
...
Unable to parse schema /components/schemas/WorkspaceConfig-Output
Unable to parse this part of your OpenAPI document: : Attempted to generate duplicate models with name "WorkspaceConfig"

This makes it difficult to reliably generate clients that cover all workspace-related endpoints.

Suggested Solution:
Consider renaming the schemas with the -Output suffix to something distinct that won't clash after normalization. For example:

• FullWorkspace-Output -> FullWorkspaceOutput
• WorkspaceConfig-Output -> WorkspaceConfigOutput

Ensure all $ref pointers throughout the openapi.json file are updated accordingly.

This change would improve the spec's compatibility with standard OpenAPI tooling and make client generation more robust

Additional Context

No response

[lukehinds]

@peppescg / @alex-mcgovern would this need patching in codegate-ui (generate post a PR merging to fix the above)?

[peppescg]

@peppescg / @alex-mcgovern would this need patching in codegate-ui (generate post a PR merging to fix the above)?

Yep, once we merge this fix we need to update the openapi.json in the UI( we have a script that do it automatically ), and generate all the ts interfaces and endpoint wrappers

[peppescg]

@lukehinds free feel to assign to me I can handle both BE and FE

[lukehinds]

@peppescg sorry I just seen your message, I pushed f41b68b