Hi @Hardik1301,
Welcome to the community!
Just as a head’s up, I changed the category of this post so it is in the monday apps & developers queue. We direct all API questions there 🙂
Best,
Rachel
I was getting a similar error this morning. I tend to agree it feels like something has changed in the last 24-48 hours as have had a series of our automations all go to pot.
Anywho, I had something similar but checking for items with a blank text field.
Previously this is what I had:
{ column_id: "text5", compare_value: [null], operator: is_empty }
I removed the explicit null
reference to this and it is now working (and returning correctly):
{ column_id: "text5", compare_value: [], operator: is_empty }
I think the change/issue might be with the null
. Try simply stripping that out and leaving an empty array. I just tried this in the playground with a board where I have checkbox values and this worked:
{ column_id: "checkbox", compare_value: [], operator: is_not_empty }
Thanks Mat I done the same changes and it is working fine.
Thanks for the clarification
Hi @Hardik1301 and @matcamp.alab,
Thanks for flagging this issue! We’ve investigated the matter and discovered that it is related to a small change on our side to the component responsible for parsing GraphQL queries.
The new component adheres more strictly to the GraphQL specification compared to our previous parser. Specifically, the compare_value
argument, which is required and non-nullable, was previously accepted with a enull]
value due to a leniency in the old parser. The new parser, however, enforces the specification more precisely, and as a result, passing enull]
for the compare_value
field is no longer valid.
Since this is a specification adherence issue, you may need to adjust your query parameters to comply with the strict requirements of the new parser. I see that you both found a query that works, but please let us know if you encounter any other issues.
Best,
Rachel
Hey Rachel,
Thanks for the acknowledgement of the change! Can I ask also; around the same time this change happened, all my requests from our automation platform that were pushing on a GET method stopped working. Changing them to POST fixed the issues across the board. The error response advising of invalid GraphQL so would that indicate it was a change in how string encoding is being handled, or has GET been disabled? Any light you can shed on that?
Hey @matcamp.alab – yes, you’re right it’s part of the same change.
We never officially supported GET requests, your requests have always had to be POSTs. It was just something we weren’t enforcing.