Hello,
I’ve been working with the Awork API for a while and recently noticed a change in the updatedOn parameter. It seems like updates are now applied in batches (either per task or per project).
Because of this, I’m currently unable to reliably use this parameter to detect changes for a single time entry.
Am I possibly querying or interpreting this parameter incorrectly, or could this be a bug?
Thank you in advance!
Hi @Katharina9 this should have been always the case in a similar fashion but there is a change which we did.
So old behavior was: When a Project or a Task changed, we updated the updatedon of the timetracking async. We need to do it, because this is important for our frontend to stay in sync with the changes, so decide when the frontend data store is updated.
But this behavior of writing into the timeentries causes a lot of db pressure, so what we do now is we calculate the updated on based of the highest value of the related entities.
So the general behavior stayed the same, when a sub entity which is in the timeentries model included changes, the updatedon of the timeentry itself is also updated.
Does that clarify what is happening?
Hi @Katharina9, we are currently checking this again and are validating how we can make the behavior more in line with how it was before. We will keep you posted here.
Hey Sebastian 
, anything new on that? Our API costs are exploding 
Hi @Sebastian14, we are considering several options but those are all complex changes so unfortunately no news yet. Is there any chance you can rely on webhooks instead?
would require a major overhaul of our logic. Furthermore with webhooks, any change to the time entry would trigger the logic. Currently, we run this every 3 hours, which saves us from having to perform multiple transactions when there are several changes to the entries. All in all our current setup seems to be the best structure I think
Got it. We will try to get the concept for this done next week so we can start making the changes, but I won’t have more news before Monday unfortunately.
great, thank you :)!
We decided to revert the behavior to how it used to be: updatedOn gets updated for changes to the time entry as well as those nested properties that are part of the model, meaning your previous logic should work and you should see a reduction in time entries updated in a specific time frame. We are testing the change internally and it will likely roll out to production tomorrow evening. I hope this helps.