- Issue created by @apotek
- Merge request !63Allow for offsetting the orange_dam_item_update_last_run_time via a configurable offset in seconds → (Merged) created by apotek
Automatically closed - issue fixed for 2 weeks with no activity.
During an API call to Orange Dam for content modified since the last time the request was made, the module currently:
1) Reads the stored `orange_dam_item_update_last_run_time` datetime.
2) Sets a "now" datetime.
3) Queues any found Orange Dam content changed since the `orange_dam_item_update_last_run_time` datetime.
4) Sets the `orange_dam_item_update_last_run_time` to the previously defined "now" datetime.
This works, but if for any reason there is a slippage in clocks between API requests, there is a theoretically possible scenario where a few items might get missed or passed over simply for the clock that sets the modification timestamp being slightly out of sync with the clock on the requesting server.
We have been seeing scenarios where items, for no discernible reason, are simply never queued. We are wondering whether this kind of scenario might be the culprit.
Allow for a configurable offset (in seconds) to deduct from the new `orange_dam_item_update_last_run_time` timestamp. This way, if the next request would ordinarily request items changed since 12:14:38 (for example), you could set an offset of, say 5 seconds, which would deduct five seconds from the timestamp for the next query, allowing the next query to capture items that might otherwise slip through the gaps, if the clock is off by a small amount.
Yes, this means some items might be queue twice, but that, aside from wasting CPU cycles, should not be an issue from a data point of view.
Create a merge request with the proposed solution.
none
none
Need to add a new config property and modify the module schema for it.
Active
2.1
Code
Automatically closed - issue fixed for 2 weeks with no activity.