Test suite unclear on what happens when duplicate job is attempted

[fj]

The test suite says that a duplicate job is not added, which is the desired behavior.

But what else happens? Is an error raised? Is false returned? How does one know if success occurred or not? The nearest I can tell is that perform just won't return a job_id:

TestJob.perform_async :arg => 1
# => "1234..."

TestJob.perform_async :arg => 1    # a duplicate!
# => nil

The test suite doesn't make it clear how to check this, since it works by looking at the queue size, which definitely isn't the correct strategy for production, since jobs are being added and removed all the time.

[mhenrixon]

Check the readme https://github.com/mhenrixon/sidekiq-unique-jobs#logging

[ivanovv]

Hm, logging is good, but what if I want to notify the user that the action they have tried failed? I mean, checking returned jid is fine if it is the recommended way. But maybe there is another way to check?

[mhenrixon]

@ivanovv could you elaborate on your needs? It is possible to use the sidekiq_retries_exhausted for some things. Also, the death_notifications in sidekiq could be used for some things.

[ivanovv]

@ivanovv could you elaborate on your needs?

@mhenrixon sure!

We have a process that uses external API to buy a resource for a company. Company has many users and one resource. We don't want users to be able to start a buying process if there is already one scheduled or running. At the same time we would like to notify a user that their attempt to buy a resource has failed. Make sense?

[mhenrixon]

Well if there is no jid returned then the job was most likely a duplicate and you could inform the user about the duplicate. Regarding how to do that exactly (I suppose you would like to mention what user is currently using the API) that is not something easily achieved with Sidekiq.

unless MyAPIConsumer.perform_async(company_id: 1)
  # notify user about that API is in use from another user
end

If you want to keep track of who checks out the API then I recommend to use some type real database where you store these things on your side. It would be possible for the gem to collect that information for you using lua scripts but it isn't exactly straight forward with redis.

[ivanovv]

Thanks a lot @mhenrixon!
I don't really care about the user holding the lock, simple notification that the operation is in progress will be sufficient.

Will create a PR with changes to README later as it was quite a task to find that information in the repo :)