cy.request parameter qs does not work for multiple keys of the same name

[Lasidar]

Current behavior

When calling cy.request with the qs option, if multiple keys of the same name are utilized in the query, cypress only uses one of them in the resulting URI.

Desired behavior

Cypress should take all query key/value pairs, regardless of if any keys are duplicated, since this is valid in a URI.

Test code to reproduce

        cy.request({
          method: "POST",
          url: "www.google.com/api",
          qs: {
              "someKey": "value1",
              "someKey": "value2",
          }})

This should result in a POST to www.google.com/api?someKey=value1&someKey=value2, but instead results in a POST to http://www.google.com/api?someKey=value2

Cypress Version

8.2.0

Other

No response

[JGjumpshot]

I am experiencing a similar issue with formData. We use .NET as our framework, my request works in postman, but when I send the request in cypress I'm sending the same key twice. I end up with the end value being set but not the first. This results in a failed request for our application.

        let requestUrl = this.getUrl(`Leads/Add`);
        if (Cypress.config().baseUrl.includes('{url}')) {
            if (leadStatus === 5) {
                const options = {
                    method: "POST",
                    url: requestUrl,
                    form: true,
                    headers: {
                        "Cookie": cookie
                    },
                    body: {
                        "__RequestVerificationToken": requestToken,
                        "LeadGuid":leadGuid,
                        "FirstName":firstName,
                        "LastName":lastName,
                        "CreatedByName": "Test User1",
                        "CreatedById":12,
                        "CreatedDate":createdDate,
                        "State": "UT",
                        "SubscribeToMailingList":false,
                        "Deceased":false,
                        "Minor":false,
                        "SourceId":15,
                        "ContactSourceId":9,
                        "Summary":summary,
                        "CaseTypeId":1,
                        "SeverityLevelId":3,
                        "OfficeId":1,
                        "LeadRoleUsersForLead.Index":1, <--- Here is the first key value pair
                        "LeadRoleUsersForLead[1].LeadRoleId":1,
                        "LeadRoleUsersForLead[1].LeadStatusId":5,
                        "LeadRoleUsersForLead[1].IsRequired":true,
                        "LeadRoleUsersForLead[1].LeadRoleDisplayName":"Intake",
                        "LeadRoleUsersForLead[1].UserId":12,
                        "LeadStatusId":5,
                        "LeadRoleUsersForLead.Index":2, <--- Here is the 2nd key value pair
                        "LeadRoleUsersForLead[2].LeadRoleId":2,
                        "LeadRoleUsersForLead[2].LeadStatusId":3,
                        "LeadRoleUsersForLead[2].IsRequired":true,
                        "LeadRoleUsersForLead[2].LeadRoleDisplayName":"Attorney",
                        "LeadRoleUsersForLead[2].UserId":12,
                        "action":"Create"
                    }
            }
            cy.log(options);
                return cy.request(options).then((res) => {
                    expect(res.status).to.eq(200);
                    return res.body;
                })
            }```

[JGjumpshot]

@jennifer-shehane @brian-mann any updates on this?

[Yethal]

@jennifer-shehane Similar behavior occurs in cy.intercept. If the url we're trying to catch contains multiple duplicated queries the req.query field will only contain the last one. Is this the same root cause or should it be filled as a separate bug?

[emilyrohrbough]

The issue you are experience is not an issue with Cypress, but instead the behavior of how JavaScript Objects handle duplicate keys. Javascript will override a duplicate key with the latest entry.

The correct way to provide a query with duplicate values for a single key is like:

it('query same key multiple times', () => {
    cy.request({
        method: "POST",
        url: "www.google.com/api",
        qs: {
            "someKey": ["value1", "value2"]
        }})
    }).then((resp) => {
         cy.log(resp.allRequestResponses[0]['Request URL'])
         expect(requestURL).to.eq('www.google.com/ap?someKey%5B0%5D=value1&someKey%5B1%5D=value2')
    })
})

Please give this a try & let me know if you experience any issues. Otherwise I think this issue can be closed for the issue reported.

I will say, when crossing-checking the query behavior when multiple values are provided for a single key for cy.request() to cy.visit(), it appears the query stringification & parsing differ.

Using my example above,

• cy.request() results in: www.google.com/ap?someKey%5B0%5D=value1&someKey%5B1%5D=value2 <--- the sameKey array is getting indexed and encoded, resulting in %5B0%5D([0]) and %5B1%5D ([0])
• cy.visit() results in: www.google.com/ap?someKey%5B0%5D=value1%value2 <-- % is , encoded

I will be logging an issue to align these behaviors & will link it here. There may be a need to provide additional qs options to configure how the query string is stringified & parsed, but we'd need to determine an aligned path forward before opening this up.

[duncanatkinson]

I am having an issue where a request is made to /path?q=1&q=2
When attempting to intercept this, I can only set routeMatcherOptions.query to a value of [key: string]: string

In addition if I attempt to use a routeHandler to assert on the query params in the request object I find that the first has been lost and I only get the q=2 query param.

The only option I can see in this case is to assert on the url which is correct, however I can see this is not ideal.

[MariamElbarbary]

I made a work around for cy.intercept by sending the path including the query params as a string

`cy.intercept({
        path: '**/path/blabla?*&rq=4&q=5',
      })` 

[cypress-app-bot]

This issue has not had any activity in 180 days. Cypress evolves quickly and the reported behavior should be tested on the latest version of Cypress to verify the behavior is still occurring. It will be closed in 14 days if no updates are provided.