What is your field type in your database and can you share an example of the value in your db that is throwing a 500 error?
I’ll try to reproduce on my side
The field is a timestamptz (not nullable). The error happens even on an empty table with no records.
Can you try to relaunch your server, the 500 error is coming from your admin backend so I’m wondering if it receives the right forestadmin schema etc.
+ Can you look at the logs on your server side, there should be additional information about the 500 error.
Yes, the error is happening on production as well as on local (including after reboots). Error logs:
backend_1 | "stack": "SequelizeDatabaseError: time zone \"gmt+0200\" not recognized\n at Query.formatError (/app/node_modules/sequelize/lib/dialects/postgres/query.js:386:16)\n at Query.run (/app/node_modules/sequelize/lib/dialects/postgres/query.js:87:18)\n at processTicksAndRejections (internal/process/task_queues.js:93:5)\n at /app/node_modules/sequelize/lib/sequelize.js:619:16\n at PostgresQueryInterface.rawSelect (/app/node_modules/sequelize/lib/dialects/abstract/query-interface.js:995:18)\n at Function.aggregate (/app/node_modules/sequelize/lib/model.js:1986:19)\n at Function.count (/app/node_modules/sequelize/lib/model.js:2037:12)
Is it perhaps possible that the forestadmin frontend is now sending through time zones as part of filter queries where it may not have before? (Just throwing out ideas here - not at all sure on the root cause). From our side, it doesnt look like we have changed anything
We are experiencing a similar issue that seems to have started happening for us roughly 20 hours ago.
We are using a different agent:
- Project name: Back Office
- Team name: It applies to all the teams
- Environment name: Production
- Agent type & version: “forest_liana”: “^7.6.7”, “rails”: “188.8.131.52”
- Recent changes made on your end if any: N/A
The request that fails to the server has the following filters query string and as seen below the value sent to the server does not use the ISO8601 format for timestamps:
"value": "Wed Jul 20 2022 10:32:33 GMT+0100 (British Summer Time)"
Ok thanks again for the clarification, we rollback to a previous stable version can you confirm that this is working for you now?
Thanks a lot,
Thanks - I can confirm that that has fixed the issue
Thanks and sorry again for the disturbance!
I can also confirm that the issue is no longer happening. Thanks for your help @lclisson
Thanks a lot for bringing this issue up and sorry again for the inconvenience!
FYI we just deployed again the incriminated release with a fix on the date filter… we took a lot of care to be sure everything is working fine, but please let us know if you find anything broken/strange again (on a new topic if this one is closed).