Please have a look at TelpeNight#1, I sent you a PR with the fix. WE can merge all in one once you approve.

There's a limitation dependent on a runtime bug. I'll fix that separately.

Oh, and you will need to rebase for CI to pass.

@greptileai

Greptile Summary

This PR fixes issue #2183 by changing how styled query parameters are assembled in the generated client code: instead of routing them through url.ParseQuery → url.Values → url.Values.Encode() (which re-encodes comma delimiters as %2C), the raw fragment returned by runtime.StyleParamWithLocation is now appended directly to a rawQueryFragments slice and joined with &. Non-styled (passthrough / JSON) parameters continue to use url.Values so they remain correctly percent-encoded. An accompanying unit test in internal/test/issues/issue-2183/ validates the serialisation and server-side round-trip for form style parameters with and without explode.

Key observations:

• The fix correctly preserves literal commas as delimiters for explode=false (e.g. color=blue,black,brown) — the core bug being addressed.
• The template change introduces a silent ordering change: styled params always appear first (in declaration order), and passthrough/JSON params appear last (sorted alphabetically). A test case mixing both parameter types would make this behaviour explicit.
• The SkipServerRoundTrip flag in the test acknowledges a known remaining limitation — values that contain commas (e.g. c%2Cd) cannot currently survive a server-side round-trip without changes to the runtime library. This is clearly documented in the test comments.
• The new issue-2183 test directory contains only the test file, with no OpenAPI spec or code-generation config, which is intentional here since the test exercises the runtime library directly rather than generated code.

Confidence Score: 4/5

• Safe to merge — the fix is well-scoped and the test coverage is adequate for the core bug, with only minor gaps around mixed parameter types and ordering edge cases.
• The template change is straightforward and the generated .gen.go files in the PR confirm it produces the expected output. The two minor issues (missing mixed styled/non-styled test case, undocumented ordering change for base-URL query params) are quality-of-life gaps rather than correctness blockers.
• No files require special attention beyond the noted style suggestions.

_{Last reviewed commit: 917dbdc}

Could you allow maintainers to push changes to your branch in the PR settings so that I can resolve the conflicts and merge, or could you do a rebase and fix them yourself?

Hello. I've opened access to maintainers.

I've tried to resolve conflicts myself. But after regenerating tests, some of them start to fail.
For example internal/test/issues/issue-2031/prefer/issue2031_test.go
Old version did encode user_ids[] as "user_ids%5B%5D". This seems to be correct.
https://www.codestudy.net/blog/is-array-syntax-using-square-brackets-in-url-query-strings-valid/
https://swagger.io/specification/#percent-encoding-and-form-urlencoded

According to the specification [] should be encoded even if allowReserved is true.

New implementation seems to violate this. So I don't think it is ready to be merged.

I resolved the conflicts, but we've caused a behavior regression with these changes (the CI will fail). I'm digging into it more. There is a behavioral change in how parameters are encoded now user_ids[]=1 isn't RFC compliant, but widely accepted in various tools, while user_ids%5B%5D=1 is spec compliant.

I pushed a fix which still encodes parameter names, but honestly, I am unsure if this is proper behavior.

There's also an OpenAPI parameter property, allowReserved which we are ignoring.

This code is also very old with an .IsStyled check in the template, which was added after basic parameters were handled. Honestly, everything should go through through the runtime.StyleParameter. I think I need to do some refactoring.

I've removed the approval for this PR for the moment while I think about this.

I believe that the better approach is to be spec compliant. Even allowReserved doesn't allow gen-delims. They should be escaped. Just like & character from the same set, as it would screw a query up.

After studding the runtime source a little bit, I think that it lacks a good test suit for serialisation/deserialisation process. The case I've started this issue from comes directly from oapi spec. Nothing extra-ordinal to be honest.