It seems as though the maximum number of _in filter parameters is 20?

[nodeworks]

If I do 20 it works, if I do anything beyond 20 it gives the error:

Validation failed for parameter 'p1'. Invalid number.

Even though it doesn't matter what number is in there, it just fails with anything past 20 in length for _in.

Any ideas?

[azrikahar]

This does sound odd, but 20 feels a bit arbitrary here as _in should allow any string (uuid) or numbers, at least that's the intended behavior and it's what I'm able to observe in the source code at a glance.

Perhaps you can try starting from 5 for example, and see whether you can reach until 25/26? Wonder if it's more of a query param length limit or payload limit rather than a "allowed value within _in" issue 🤔

It would also be very helpful if you can share the error shown from that request, or even error logged by the server, if any.

[br41nslug]

If the problem is related to request size then using JSON formatting instead would save some space: &filter={"id":{"_in":[1,2,3,4,5]}}

[nodeworks]

The error is based on the total number not the actual numbers of the parameters. It's very strange. I've been getting around it by batching anything over 20. I also increased MAX_PAYLOAD_SIZE to 10mb and that didn't affect it either. Someone strange is definitely happening for sure. I'm using directus 9.21.0 docker image.

[nodeworks]

Here's a GET request that returns a 200 code and an empty array and has 23 parameters:

/items/projects?fields[]=id&fields[]=project_id&fields[]=name&fields[]=long_name&fields[]=default_sub_type.*&fields[]=funding_years.funding_year&fields[]=project_sub_types.project_sub_type.*&fields[]=regions.region.*&fields[]=categories.category.*.*&filter[project_id][_in][0]=117990&filter[project_id][_in][1]=117991&filter[project_id][_in][2]=117992&filter[project_id][_in][3]=126244&filter[project_id][_in][4]=1223051&filter[project_id][_in][5]=122305&filter[project_id][_in][6]=129388&filter[project_id][_in][7]=131082&filter[project_id][_in][8]=130988&filter[project_id][_in][9]=130989&filter[project_id][_in][10]=130990&filter[project_id][_in][11]=131055&filter[project_id][_in][12]=131221&filter[project_id][_in][13]=131232&filter[project_id][_in][14]=131233&filter[project_id][_in][15]=131234&filter[project_id][_in][16]=131235&filter[project_id][_in][17]=131063&filter[project_id][_in][18]=131095&filter[project_id][_in][19]=2022+NODE+SPLITS+CAP+LABOR&filter[project_id][_in][20]=133863&filter[project_id][_in][21]=133864&filter[project_id][_in][22]=133865&filter[project_id][_in][23]=133866

[nodeworks]

If I remove the [21] and [22] parameters it works fine and returns all the results. so strange!

[nodeworks]

@azrikahar I can show you the raw results and so forth in private if you'd like

[nodeworks]

Another update. It seems as though the request filter params are getting converted to an Object past 20 array items. This changes the "length" to be 1, instead of whatever the array length should be. I think this is happening maybe at the Express level? But i'm not exactly sure.

[nodeworks]

@azrikahar

Another update! So I tracked down where this is happening. It's happening in the "qs" library. In api/src/app.ts there is a line:

app.set('query parser', (str: string) => qs.parse(str, { depth: 10 }));

Setting it to:

app.set('query parser', (str: string) => qs.parse(str, { depth: 10, arrayLimit: Infinity }));

fixes that problem.

Should I file a bug ticket for this?

[azrikahar]

Thanks again for debugging this! Pardon for not being able to get back to you sooner, but I've opted to respond in the ticket you have promptly opened: #16745 👍