swagger-api / swagger-api/swagger-codegen

[Java] Handling optional query param

Open
#7,115 1 comment 4 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Mustache
Stars
17.8k
Forks
6k
PR merge metrics
No merged PRs in 30d

Description

We have codegen(2.2.2) to generate java client code for our tests. In a recent change, an optional query parameter was added to one of the APIs with default value specified.

This shouldn't cause any issue as its optional and also has default value, so it does support backward compatibility. However, the generated code changed the method signature from:

apirequest(param1)

to apirequest(param1, param2) - where param2 is optional and has default value defined

In our tests, it was calling apirequest(param1) which caused tests to break as there was now mismatch in no. of params for the method causing compile error.

I tried using useOptional=true in additional properties and set datatype for optional param to Optional, did not help - generated same method with no change in signature.

Tried upgrading to 2.2.3, but it crashed while processing some of the APIs where body param is List I see it fixed as issue #6079 (https://github.com/swagger-api/swagger-codegen/commit/e8bdf71ffcc4631c82cded65425d5662d62d5057#diff-0c1b6d04d7c2c41f87f7c710a5610d88) but is not yet available. Temporarily tried setting to String in such cases, just to see if it helps the actual problem, the generated method still remained same with 2 params causing test to fail.

Not sure about how we can overcome this situation, so as not to break our tests with addition of optional parameter. Any suggestions/pointers would be of real help

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No repository file or test is named. Start by reproducing the generated Java client with an optional query parameter and compare the one-argument and two-argument signatures; then inspect the Java generator path and the useOptional additional property. Done means the project has a confirmed backward-compatible behavior or a clearly documented limitation, with the related generated-client test passing.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
tooling
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.