We run a query every 5 minutes to check on the recent picks and ensure items were all scanned and items all had weights, etc. This was working fine until a few months ago, but then we noticed that randomly now it seems to automatically be 5 minutes behind.
For example, if we run the query and use “query {picks_per_day(date_from:“2021-06-25T16:58:50”)”, it will really do it from about 5 minutes and 70 seconds before that (so it would be as if we had entered “T16:52:40”.
Do you know this can be fixed? Or if this was an intentional change by the engineers, do you know the exact seconds that it is behind for that query so we can factor that into our request. Thank you!
If it is helpful, this is an example of a request_id where you can see this (the query was date_from: 19:08:51 but the response has results from before that time (i.e. 19:06:19) :
@kokua Unfortunately we haven’t been able to figure out a good workaround. We tried randomly guessing what the offset was (i.e. X minutes or X seconds) but that doesn’t seem to work well since we can’t determine what the number is. This seems to have started being an issue around March of this year I believe.
@atlatin one thing I am doing for now is fetching a generous range of picks and not storing them if I already have their node_id instead of trying to guess the magic math.
Unsure if this affects you too, but I am noticing that I must fetch records using timestamps in EST (not even EDT) and the timestamps that come back are UTC. So this also caused an issue recently as daylight savings shifted recently as well.
@kokua that sounds like a good workaround, just unfortunately over my head on how to process in that manner (comparing to existing node_id and then not storing).
The EST issue you mentioned is the same here and caused problems for us during the shift from daylight savings until we accounted for that hour difference.