When programming, it is really important to put fail-safes into your code to deal with potential errors. This is code that would serve no purpose if everything executes exactly like you want it to, but unfortunately, you should never program for a perfect world. Other things can happen that are out of your control that make it imperative to put in protective measures to prevent errors from happening. A litany of things can happen for why you might need to write protections in your code, including: someone else on your team is calling your method and passing the wrong type of variable, you’re using a third party API that may change somewhat in the future, you’re relying on timing methods that could somehow misfire, or you’re just going back to your own code after a long time and forget some of the ins and outs (hopefully proper commenting in your code can prevent this as well).
This blog post is especially timely because we here at HangZone have been dealing with a timing issue in one of our apps. We have server logic that executes at a scheduled time that must run at exactly that time. If it calls more than a couple minutes to one side or the other of our desired execution time, we have issues, or if it calls more than once, we have even larger issues. So, here are the protections that we need in this method: 1) Make sure the code only runs during the desired time. 2) Make sure it is only runs once.
The first and simplest fail-safe that we use is a method that checks the time and sees if it is the correct time for the method to execute. This is a scheduled method that is supposed to execute daily at 0:00 GMT (This translates to 7:00pm EST).
var theTime = modules.moment().unix()
var secondsIntoDay = theTime % (60 * 60 * 24)
var readyToCallEndpoint = false
if (secondsIntoDay > ((60 * 60 * 24) - (60 * 10)) || secondsIntoDay < (60 * 10)) {
readyToCallEndpoint = true
}As you can see, the method starts by getting a current timestamp in seconds. Next, it determines what the current time is by doing a modulo on the number of seconds in a day. The method then checks to see if seconds into the current day falls in a ten minute range around the desired execution time. If it does, readyToCallEndpoint is set to true, and the rest of the method, which is wrapped in an if statement requiring readyToCallEndpoint being true, is executed.
This technique works great for making sure that the code only executes at the correct time. However, the method could conceivably get called more than once, which would result in all sorts of problems. To prevent this from happening, we will add a new variable called lastExecutionOfCode, which is a timestamp that will be saved to the database. It will be retrieved from the database at the start of this code. After checking to see that the time is inside the desired code execution time, the code will next check to see if the last execution time was at least 23 hours ago. If it passes this test, the current timestamp is saved to the database as lastExecutionOfCode and readyToCallEndpoint is set to true.
So, that’s it. Of course, there are other ways that you could write protections into the code to prevent timing issues, but this is how we chose to tackle the problem. Thanks for visiting HangZone!