We are suddenly running into INTERNAL_SERVER_ERROR responses for Products queries that use a date search filter, and where the filter value is wrapped in single quotes.
{
"errors": [
{
"message": "Internal error. Looks like something went wrong on our end.\nRequest ID: c36757d9-8484-41c0-bcaf-10a1eb71e2b1 (include this in support requests).",
"extensions": {
"code": "INTERNAL_SERVER_ERROR",
"requestId": "c36757d9-8484-41c0-bcaf-10a1eb71e2b1"
}
}
]
}
Interestingly, other connection types, like customers and orders, the date filter continues to work whether the value is wrapped in quotes or not.
If I remove the quotes from the date filter it works. But I am not sure why the syntax is suddenly breaking (within past day or two), and to make it even more confusing, why the issue appears to be specific to products query.
without any single quotes, and it should follow that created_at would use the same syntax pattern. Can you update your app to follow this pattern? It’s possible the date filter with single quotes was not intended to be working. Other resources like customers should also use the “updated_at:>2019-12-01” format too - according to our docs.
Well, it appears that the issue may be more specific to dates with times.
When running a query against orders, based on a specific time..
This works correctly:
created_at:>'2023-12-12T22:45:00+0000' AND created_at:<'2023-12-14T22:30:00+0000'
This does not return correct orders (no quotes):
created_at:>2023-12-12T22:45:00+0000 AND created_at:<2023-12-14T22:30:00+0000
But of course, for products, the query with quotes that should work correctly is getting an INTERNAL_SERVER_ERROR..
So… should this actually work for products? or is there a different/correct way to use date filters that include time and timezone?
I want to also re-emphasize that the reported issue related to product query just suddenly stopped working. We have customers who have had automations running for months without issue…