Object is not transformed into the URL variable correctly

[altarrok]

We are using SpringDoc to generate the openapi specs of our backend, and we are using a feature of SpringDoc where commonly used Pageable object parameter is mapped automatically to openapi specs. The result of the mapping looks like this:

As you can see the Pageable parameter is defined as object. The generated request URL looks like this:

http://localhost:8080/hackathon/search?page=0&size=1&sort=location

So we can see that swagger-ui generates the correct request URL for the given Pageable object.

However -problem begins here-, when the generated client using openapi-typescript-codegen is used to make a backend call, the request URL looks like this:

http://localhost:8080/hackathon/search?pageable=%5Bobject%20Object%5D

Tracking the code, I can see that in request.ts::getQueryString arrays are accounted for but the objects aren't, and therefore the Pageable object is casted to a string, resulting in the given bug.

Is there a possible fix on our side (although I doubt that)?

A possible fix on the library side (I haven't tested) may be to call the getQueryString method recursively for each entry in the object, and concatenating the result (qs).

[ferdikoomen]

@altarrok There is a fix for that in the current development branch (complex query params support). This should fix your issue. Once i have a few more things fixed i will push a new version to NPM

[altarrok]

Thanks a lot @ferdikoomen !! Let me know if we can contribute in some way, thanks for keeping the library updated

[ferdikoomen]

@altarrok New version is pushed to NPM 0.13.0 Could you check if that resolves your issue?

[ferdikoomen]

@altarrok New version is pushed 0.15.0, that should include all options (nested props, arrays, etc.)

[altarrok]

@ferdikoomen unfortunately the fix doesn't help our case (from my original issue):
As you can see the Pageable parameter is defined as object

The fix only works for lists, not objects, objects are still translated as pageable=%5Bobject%20Object%5D which is the issue. I believe there is no case where this 'feature' is useful, so it is a bug. Please let me know what we can do about this

[ferdikoomen]

@altarrok do you by change have a link to the spec or a copy of the spec that i can check? Im mostly interested in the definition of that parameter. That would make it easier to reproduce the scenario

[altarrok]

@ferdikoomen this is the openapi spec for pageable we are using:

{
    "Pageable": {
        "type": "object",
        "properties": {
            "page": {
                "minimum": 0,
                "type": "integer",
                "format": "int32"
            },
            "size": {
                "minimum": 1,
                "type": "integer",
                "format": "int32"
            },
            "sort": {
                "type": "array",
                "items": {
                    "type": "string"
                }
            }
        }
    }
}

I believe in request.ts::getQueryString line#45, the value is being checked to be an array, but there is no other check that if the value is a string or not, but it is being casted to a string downstream. My current best solution would be to check if the type of the value is a string, if not, check if it is an array, if not accept it as an object and call recursively using the objects key value pairs. That way, an object containing other objects, strings, or arrays can be flattened to a query string. Let me know what you think

[ferdikoomen]

@altarrok I assume you then have something like this in the operation parameters right?:

"parameters": [
    {
        "description": "This is a pageable parameter",
        "name": "pageable",
        "in": "query",
        "schema": {
            "$ref": "#/components/schemas/Pageable"
        }
    }
],

I'm testing this now with a client, will come back with results in a bit

[ferdikoomen]

@altarrok When im using the latest version (0.18.1), then i see the following behaviour

When im sending the following parameter:

parameter: {
   page: '0',
   size: '1',
   sort: ['location']
}

Then this is converted to:

parameter%5Bpage%5D=0&parameter%5Bsize%5D=1&parameter%5Bsort%5D%5B0%5D=location

If we decode this, then it looks like:

parameter[page]=0&parameter[size]=1&parameter[sort][0]=location

Our backend (NodeJS Express) just parses this and parses this as:

parameter: {
   page: '0',
   size: '1',
   sort: ['location']
}

That seems exactly right... Are you using the latest version of the generator?

[altarrok]

@ferdikoomen we were using npx. Specifying the version now, we got the same behavior as you do. However this behavior: pageable[sort]=LOCATION is very much different from the intended and swagger behavior: sort=LOCATION

If you disagree with this, I respect your opinion, and please let me know so that I can fork and fix the issue. Thanks!

[ferdikoomen]

@altarrok Do you have the full spec for me (if you cannot send it via github, then please send me an email: info@madebyferdi.com). Then i'll have a look to see why this generated differently.