Questions on using this package for repeating jobs that a user can turn on and off

[jamauro]

Thanks for putting this package together. I’m thinking of using it for a particular use case and am wondering if I’m thinking about it correctly.

In my app, users can create an automation that could trigger daily or monthly. They can also turn this automation off or turn it back on later.

It’s mission critical that a user’s automations complete successfully and don’t interfere with other users’ automations. Here’s how I think I should set things up based on the docs:

// register a function for daily and monthly orders
Jobs.register({
  async createOrder(userId, data, frequency) {
    // fetch some other data here to set up the next step
    await externalApi.postOrder(…)
    this.reschedule({in: frequency}); // {days: 1} or {months: 1}
  }
})

———————————————
// user takes an action to create a new repeating automation 
const repeatingOrderId = RepeatingOrders.insert({
  userId,
  frequency,
  data,
  active: true
})

// create a new job
const jobDoc = Jobs.run("createOrder", userId, data, frequency)

// update the repeating order with the jobId so we can get it later and remove
RepeatingOrders.update(repeatingOrderId,
  {$set: {jobId: jobDoc._id}} 

———————————————
// TIME PASSES
// user decides to stop the automation 
const repeatingOrder = RepeatingOrders.findOne(id)

Jobs.remove(repeatingOrder.jobId)

RepeatingOrders.update(repeatingOrder._id,
  {$set: {active: false}}
)

A few questions:

1. Is there a better way to approach this than the above?
2. Would it make any difference to have separate functions based on frequency, e.g. createDailyOrder, createMonthlyOrder?
3. Is there a way to make sure the job is only run during weekdays?
4. Would I need to do anything special if I plan to use a service that has auto scaling servers?

[wildhart]

Hi @jamauro, thanks for considering this package.

Your proposal above looks fairly solid and I think should meet your requirements. To answer your questions:

1. I don't think so, your proposal looks sound.
2. No, I think it makes sense to use the same function with a frequency parameter.
3. See below.
4. No, wildhart:jobs is designed from the ground-up so that the jobs only run on one of your servers - if that server stops then another server will take over the job queue after a short delay. Take a look at the parameters to Jobs.Configure, particularly the maxWait parameter and also make sure setServerId is not a constant string (which can be used to eliminate the wait period on single server deployments).

To expand on 3: there isn't a native way to prevent a job from rescheduling itself in a weekend. I guess you could do one of two things:

• instead of this.reschedule({in: frequency}) calculate the new date yourself, avoiding weekends, and do this.reschedule({on: newDate})
• have another job which runs every Friday night and pauses the createOrder job queue with Jobs.stop("createOrder"), and another job on Monday morning which unpauses it. The jobs will then all run in sequence when the queue is unpaused.

Also you'll need to give thought to how you define a 'weekend', particularly if you have users in different time zones, or your users are in one time zone but your server running in UTC...

[jamauro]

Great. Appreciate you taking look and providing the helpful info. I’ll give it a go and report back if I discover anything that might be helpful to others.

One thing I missed before is this.reschedule returns a new jobId so I think that means I’ll need to update RepeatingOrders with that new jobId within the registered Job function createOrder. If that’s wrong, please let me know.