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

When generating request URIs, the generated code uses Query for the query type, which escapes characters like +, which should not escaped, for instance, for the Kubernetes API client.

In the Kubernetes API client, we should be able to generate queries like ?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29 (from https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#list-and-watch-filtering). Right now, the generated URIs URL-encode the plus signs, which the API server rejects.

openapi-generator version

Commit number c9737cf97d5e31936639842d389118e980ee85a9 (from https://github.com/kubernetes-client/haskell/blob/master/settings)

OpenAPI declaration file content or url

https://github.com/kubernetes-client/haskell/blob/master/kubernetes/openapi.yaml

Command line used for generation

In the directory where https://github.com/kubernetes-client/haskell/ is checked out:
../gen/openapi/haskell.sh . ./settings

Steps to reproduce

Build the generator.
Use it in a code base that does something like the following:

let request = listEndpointsForAllNamespaces (Accept MimeJSON)
    selector = LabelSelector $ "foo+in+(bar)"
in do
  _ <- dispatchMime' manager config $ request -&- selector

Verify that the generated request has URL-encoded the + signs.

Related issues/PRs

Suggest a fix

To resolve this situation, the generated code should use PartialEscapeQuery instead, which sadly is a more complex type as the underlying items are no longer Maybe ByteString, but instead are EscapeItem, so it becomes a larger refactoring