Incorrect routing when the query parameter is in the configuration

[Burgyn]

Hi guys.

I discovered strange and different routing behavior between versions 22.0.1 and 23.0.0.

Expected Behavior

In version 22.0.1 the routing works well as expected.
We have the following configuration:

{
    "DownstreamPathTemplate": "/{tenantId}/products?{everything}",
    "UpstreamPathTemplate": "/{tenantId}/products?{everything}",
    "UpstreamHttpMethod": [ "Get" ]
},
{
    "DownstreamPathTemplate": "/{tenantId}/products/{everything}",
    "UpstreamPathTemplate": "/{tenantId}/products/{everything}",
    "UpstreamHttpMethod": [ "Get" ]
},

When I call a request

GET localhost/1/products/1

then the correct route "/{tenantId}/products/{everything}" is selected.

Actual Behavior

In version 23.0.0 the "DownstreamPathTemplate":"/{tenantId}/products?{everything}" path is chosen for some reason, which is not correct.

Specifications

• Version: >23.0.0

---

Maybe this PR? #748

Any idea for a quick fix on my part?
Thank you very much.

[raman-m]

Eliminate the initial redundant route as it is inherently included in the subsequent Catch All route.

It should be one route only

{
    "DownstreamPathTemplate": "/{tenantId}/products/{everything}", // all query strings are included
    "UpstreamPathTemplate": "/{tenantId}/products/{everything}",
    "UpstreamHttpMethod": [ "Get" ]
},

Also, note that if no Priority is defined, then the first matching route prevails! This explains the odd behavior observed.

[raman-m]

Reported once again

• Incorrect Routing when a configuration exists with query param wildcard #2132

[raman-m]

@Burgyn Although I haven't been able to reproduce this bug yet, we aim to address it in the September'24 or, at the latest, in the October'24 while working on issue #2132 which is prioritized now. I am also open to any contributions you may have.

[raman-m]

🤣 Reported once again: #2169