Record retrieval queries longer than 16,000 chars not handled

[martinopic]

Hi,

I really appreciate your client and I would like to use it for a project but there is an edge case that is not handled: for record retrieval requests longer than 16,000 chars (e.g. when having lots of conditions or fields to retrieve) the GET will fail, the 16,000 GET request is an Airtable limit and the only possible documented workaround is to do the request as a POST with the parameters in the body

See https://airtable.com/developers/web/api/list-records :

Note Airtable's API only accepts request with a URL shorter than 16,000 characters. Encoded formulas may cause your requests to exceed this limit. To fix this issue you can instead make a POST request to /v0/{baseId}/{tableIdOrName}/listRecords while passing the parameters within the body of the request instead of the query parameters.

I think this is something specific of SelectQuery so this code should go there. Unfortunately there is no way currently to know if the final URI will be > 16,000 chars so I think there are 2 ways:

• Let Client provide this information adding a getBaseUri() (which is what is missing to calculate the complete uri length) or getCompleteUri(string $uri) to Client or getCompleteUriLength(string $uri) method. This way the decision whether to switch to POST could be done transparently by SelectQuery by looking at the final URI length.
• Let users force "POST" on SelectQuery

If you are ok with any of these two methods (I think the first is more in line with the library) I can provide a patch.

[eugenezadorin]

Hi! Thanks for noticing this issue.

At first glance, the simplest solution is to use POST-request to /v0/{baseId}/{tableIdOrName}/listRecords route all the time, even for queries less than 16,000 chars. In that case we won't need any calculations here.

What do you think about it?

[martinopic]

Yes, I agree, simpler solution.

Just a little doubt on why Airtable itself did not adopt the same unified approach but probably it's just for "historical reasons" (that is: they realized later on there could be the need for queries longer than 16.000 chars and offered this alternatives while maintaining the previous for API compatibility reasons.

Will you make the change yourself?

Thanks

[eugenezadorin]

Fixed in v1.0.1

All tests passes, so I hope there are no pitfalls here 😊