[BUG] [haskell-http-client]: Cannot create HTTP client for Docker

[egormalyutin]

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• What's the version of OpenAPI Generator used?
• Have you search for related issues/PRs?
• What's the actual output vs expected output?
• [Optional] Bounty to sponsor the fix (example)

Description

openapi-generator successfully generates HTTP client for Docker, but I can't compile it using stack haddock. It ends with this error:

[ 6 of 26] Compiling DockerEngine.Model ( lib/DockerEngine/Model.hs, .stack-work/dist/x86_64-linux-tinfo6/Cabal-2.4.0.1/build/DockerEngine/Model.o )

/home/egorcod/Документы/openapi-docker/lib/DockerEngine/Model.hs:6391:51: error:
    Not in scope: type constructor or class ‘Array’
    Perhaps you meant ‘A.Array’ (imported from Data.Aeson)
    Perhaps you want to add ‘Array’ to the import list in the import of
    ‘Data.Aeson’ (lib/DockerEngine/Model.hs:34:1-41).
     |
6391 |   , systemDataUsageResponseContainers :: !(Maybe [Array]) -- ^ "Containers"
     |

openapi-generator version

> docker run --rm openapitools/openapi-generator-cli version
4.0.0-SNAPSHOT

OpenAPI declaration file content or url

https://docs.docker.com/engine/api/v1.39/swagger.yaml

Command line used for generation

docker run --rm -v ${PWD}:/local openapitools/openapi-generator-cli generate -i https://docs.docker.com/engine/api/v1.39/swagger.yaml -g haskell-http-client -o /local

Steps to reproduce

> mkdir openapi-docker
> cd openapi-docker
> docker run --rm -v ${PWD}:/local openapitools/openapi-generator-cli generate -i https://docs.docker.com/engine/api/v1.39/swagger.yaml -g haskell-http-client -o /local
> stack haddock

Related issues/PRs

Not found any.

Suggest a fix

Perhaps you meant ‘A.Array’ (imported from Data.Aeson)
Perhaps you want to add ‘Array’ to the import list in the import of
    ‘Data.Aeson’ (lib/DockerEngine/Model.hs:34:1-41).

[auto-labeler]

👍 Thanks for opening this issue!
🏷 I have applied any labels matching special text in your issue.

The team will review the labels and make any necessary changes.

[wing328]

Thanks for reporting the issue.

cc @jonschoning

[egormalyutin]

@wing328 For an unknown reason, openapi-generator not generates ContainerSummary model. I think, it caused this error.

[jonschoning]

  ContainerSummary:
    type: "array"
    items:
      type: "object"
      properties:
        Id:
          description: "The ID of this container"
          type: "string"
          x-go-name: "ID"
        Names:
          description: "The names that this container has been given"
          type: "array"
          items:
            type: "string"
        Image:
          description: "The name of the image used when creating this container"
          type: "string"
        ImageID:

[main] INFO  o.o.codegen.DefaultGenerator - Model ContainerSummary not generated since it's an alias to array (without property) and `generateAliasAsModel` is set to false (default)

openapi-generator/modules/openapi-generator/src/main/java/org/openapitools/codegen/DefaultGenerator.java

Lines 443 to 449 in dc78405

	} else if (ModelUtils.isArraySchema(schema)) { // check to see if it's an "array" model
	if (!ModelUtils.isGenerateAliasAsModel() && (schema.getProperties() == null || schema.getProperties().isEmpty())) {
	// schema without property, i.e. alias to array
	LOGGER.info("Model " + name + " not generated since it's an alias to array (without property) and `generateAliasAsModel` is set to false (default)");
	continue;
	}
	}

This occurs because DefaultGenerator.java thinks that ContainerSummary has no properties, and so it refuses to generate the model.

I do not think it's an issue with the haskell-http-client code but rather with the DefaultGenerator logic.

[thomasjm]

@jonschoning is there a way we can work around this? I tried manually correcting the import and the big Model.hs compiled successfully after that.

It seems like we're tantalizingly close to building the Docker client in Haskell, which hasn't been possible for a long time. There are only a couple more glitches after this where the generator emitted UNKNOWN_BASE_TYPE instead of a real type, so I'd love to get this working.

[jonschoning]

@thomasjm if other languages/generators also cannot generate the docker spec, it's a problem with the core parsing logic. I only really maintain the Haskell client bits, and don't have a lot of free time to fix other issues.
I'll investigate if I can find for a workaround

[thomasjm]

Thanks! If you happen to know who would be better to ask then I can bug them too :)

[thomasjm]

I've put some more work into this and made some progress. Let me record some notes here in case it helps anyone:

• I was able to build the v1.30 API by making some manual tweaks to fix some glitches from the codegen. In particular, I was able to get it to generate ContainerSummary by editing the swagger.yaml to move it to the "Definitions" sections; see this commit: codedownio/docker-engine@ca0aa77.
• After this, I realized that the spec for v1.30 has other problems. It doesn't give proper names to several of the response types, such as the ContainerInspect response. I started making more improvements to swagger.yaml before noticing that later versions of the Docker spec are better.
• After studying the various Docker engine versions I decided that v1.36 is the lowest version that is reasonably sane. In particular, it's the first version that
  a) Actually parses the HostConfig.PortBindings value correctly in inspect responses, and
  b) has a proper title on inspect responses (and several other responses).

You can find a successfully buildable version of v1.36 on my branch here: https://github.com/codedownio/docker-openapi/tree/v1.36

[metint]

I can confirm that this is not haskell-http-client specific. Today I tried to generate cpp-restsdk code for Docker Engine API (first for v1.40, later for v1.36), but obtained a non-compilable code with similar symptoms (e.g. UNKNOWN_BASE_TYPE). There is also a similar issues for rust-client #2532