Possible bug: orders-api return limit - 1 records when sorted by CREATED_AT = ASC

Questions
1

I called /v2/orders/search and specified the sort_field on CREATED_AT, with limit, like so:

{
    "location_ids": [ "ABC" ],
    "limit": 2,
    "query": {
        "sort": {
            "sort_field": "CREATED_AT",
            "sort_order": "ASC"
        }        
    }
}

If the sort_order is ASC, the API returns only 1 order in the orders array. If the sort order is DESC, the API returns 2 orders as expected. The cursor attribute is returned in both cases. There are more than 30 orders in my test account. It is even more strange if limit is 1. I’d get only the cursor attribute returned with no orders attribute when sort_order = ASC.

Overall, it seems like orders API would return limit - 1 records if sort_order = ASC. I have not tested other sort_field values, though.

I do not believe this is the intended behavior. Can someone from Square please confirm? Thanks.

2

:wave: Looks like it’s only returning COMPLETED orders instead of all the orders. I’ve reached out to the team about this. :slightly_smiling_face:

3

Thanks for looking into this. I have more than one COMPLETED orders in my account. Regardless, changing from DESC to ASC should not result in # of records being returned – the sort order should just flip.

4

According to the team the limit is the maximum number of results to be returned in a single page. It is possible to receive fewer results than the specified limit on a given page and you’ll need to paginate through the results. :slightly_smiling_face:

5

Hi Bryan-Square. Sorry for a delayed response. I fully understand how pagination function works in general. My point still remains. I have 30+ orders in my test account. When I query for them with limit set to 2, I should get 2 back in the each page, regardless of the sort_order. Currently this is not the case. This seems like a bug in this particular API.

Upon further testing, I found that even if I include the limit parameter without the sort_order (like the example below,) the error remains:

{
    "location_ids": [
        "123456"
    ],
    "limit": 2
}
  • if limit is not included or if its value is very high (e.g. 999) → I get all orders back (more than 30 in my case) with no cursor (as there is nothing to page further) → This is correct.
  • if limit is 1, I get 0 record back with just cursor → This seems incorrect.
  • if limit is 2, I get 1 record back with cursor → This seems incorrect.
  • if limit is 3, I still get 1 record back with cursor → This seems incorrect.
  • if limit is 4, I get 2 records back with cursor → This seems incorrect.
  • if limit is 5, I get 3 records back with cursor → This seems incorrect.
  • if limit is 6, I get 3 records back with cursor → This seems incorrect.
    …
  • if limit is 9, I get 5 records back with cursor → This seems incorrect.
  • if limit is 10, I get 5 records back with cursor → This seems incorrect.

By observation, it seems that the API will return limit / 2 records (with some rounding errors.)

And if I call for the next page (by including cursor in the call,) the number of records in the second page will also not honor the limit request parameter. For example, if limit = 9, I’d get 5 records in the first page, 6 records on the second page, 1 record on the third page, and 7 records on the 4th page.

Given these test results, the pagination on this /v2/orders/search endpoint does not work reliably in my opinion. I have not tested it on any other Square endpoint. I think you should have your team look into it.

6

I’ll definitely share this with the team however as previously mentioned the limit is the maximum number of results returned and it’s possible to receive fewer results than the specified limit with a cursor to paginate with. :slightly_smiling_face: