Due to network or hardware failures, it can happen that one of your cronjobs will not run at the time you specify in the schedule. Your code should be built in a way that it can be re-run at a later time (when the failure is resolved).

For example, if you are synchronizing data with another service once every day, your cronjob should not only synchronize changes from the last 24 hours. If you do this and a network failure will delay the execution of your job by 5 hours, you will only synchronize changes from hour 6-29, but forget changes from hour 1-4.

Instead your cronjob should remember the last time a sync was performed successfully, and sync all the changes that happened after that.

Henning Koch

makandra.com

Say thanks1

Last edit

Over 6 years ago

Henning Koch

Keywords

background, tasks, craken, whenever

License

Source code in this card is licensed under the MIT License.

Async control flow in JavaScript: Promises, Microtasks, async/await

Slides for Henning's talk on Sep 21st 2017.

Understanding sync vs. async control flow

Talking to synchronous (or "blocking") API

print('script start')
html = get('/foo')
print(html)
print('s...

Delivering Carrierwave attachments to authorized users only

Preparation

To attach files to your records, you will need a new database column representing the filename of the file. To do this, add a new migration (rails g migration <name>) with the following content:

class AddAttachmentToNotes...

Posted by Henning Koch to makandra dev (2014-08-07 07:35)

Your Cronjobs should not rely on a perfect schedule

Related cards:

Understanding sync vs. async control flow

Talking to synchronous (or "blocking") API

Preparation

Summary

Introduction