0

I'm using Sidekiq to perform some heavy processing in the background. I looked online but couldn't find the answers to the following questions. I am using: 

Class.delay.use_method(listing_id)

And then, inside the class, I have a 

self.use_method(listing_id)
    listing = Listing.find_by_id listing_id
    UserMailer.send_mail(listing)
    Class.call_example_function()

Two questions:

  1. How do I make this function idempotent for the UserMailer sendmail? In other words, in case the delayed method runs twice, how do I make sure that it only sends the mail once? Would wrapping it in something like this work?

    mail_sent = false if !mail_sent UserMailer.send_mail(listing) mail_sent = true end

I'm guessing not since the function is tried again and then mail_sent is set to false for the second run through. So how do I make it so that UserMailer is only run once.

  1. Are functions called within the delayed async method also asynchronous? In other words, is Class.call_example_function() executed asynchronously (not part of the response / request cycle?) If not, should I use Class.delay.call_example_function()

Overall, just getting familiar with Sidekiq so any thoughts would be appreciated.

Thanks

Delos Chang
  • 1,823
  • 3
  • 27
  • 47

2 Answers2

8

I'm coming into this late, but having been around the loop and had this StackOverflow entry appearing prominently via Google, it needs clarification.

The issue of idempotency and the issue of unique jobs are not the same thing. The 'unique' gems look at the parameters of job at the point it is about to be processed. If they find that there was another job with the same parameters which had been submitted within some expiry time window then the job is not actually processed.

The gems are literally what they say they are; they consider whether an enqueued job is unique or not within a certain time window. They do not interfere with the retry mechanism. In the case of the O.P.'s question, the e-mail would still get sent twice if Class.call_example_function() threw an error thus causing a job retry, but the previous line of code had successfully sent the e-mail.

Aside: The sidekiq-unique-jobs gem mentioned in another answer has not been updated for Sidekiq 3 at the time of writing. An alternative is sidekiq-middleware which does much the same thing, but has been updated.

There are numerous possible solutions to the O.P.'s email problem and the correct one is something that only the O.P. can assess in the context of their application and execution environment. One would be: If the e-mail is only going to be sent once ("Congratulations, you've signed up!") then a simple flag on the User model wrapped in a transaction should do the trick. Assuming a class User accessible as an association through the Listing via listing.user, and adding in a boolean flag mail_sent to the User model (with migration), then:

listing = Listing.find_by_id(listing_id)

unless listing.user.mail_sent?
  User.transaction do
    listing.user.mail_sent = true
    listing.user.save!
    UserMailer.send_mail(listing)
  end
end

Class.call_example_function()

...so that if the user mailer throws an exception, the transaction is rolled back and the change to the user's flag setting is undone. If the "call_example_function" code throws an exception, then the job fails and will be retried later, but the user's "e-mail sent" flag was successfully saved on the first try so the e-mail won't be resent.

Andrew Hodgkinson
  • 4,379
  • 3
  • 33
  • 43
1

Regarding idempotency, you can use https://github.com/mhenrixon/sidekiq-unique-jobs gem:

All that is required is that you specifically set the sidekiq option for unique to true like below: 

sidekiq_options unique: true

For jobs scheduled in the future it is possible to set for how long the job should be unique. The job will be unique for the number of seconds configured or until the job has been completed.

*If you want the unique job to stick around even after it has been successfully processed then just set the unique_unlock_order to anything except :before_yield or :after_yield (unique_unlock_order = :never)

I'm not sure I understand the second part of the question - when you delay a method call, the whole method call is deferred to the sidekiq process. If by 'response / request cycle' you mean that you are running a web server, and you call delay from there, so all the calls within the use_method are called from the sidekiq process, and hence outside of that cycle. They are called synchronously relative to each other though...

Uri Agassi
  • 36,848
  • 14
  • 76
  • 93