Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

The job gets JID and goes to dead right away #522

Closed
migalenkom opened this issue Jun 25, 2020 · 6 comments
Closed

The job gets JID and goes to dead right away #522

migalenkom opened this issue Jun 25, 2020 · 6 comments

Comments

@migalenkom
Copy link

Describe the bug
We have one instance with sidekiq and after some time it starts to work incorrectly. We go to console and call HeartbeatWorker.perform_async(false, nil) , it shows JID and goes to dead right away.

HeartbeatWorker.perform_async(false, nil)
=> "72d9a59868d59c268c063780"

In logs, I can see

2020-06-25 08:26:29.174996 W [19701:processor] Sidekiq -- the unique_key: uniquejobs:17efb573488d8206c5190fbaaa8931f8 is not locked, allowing job to silently complete

image

Expected behavior
The worker processed after it get JID and it goes to dead only when we have a job in progress with the same args.

Current behavior
The worker is not processed it goes to dead

Worker class

class UniqueWorker
  include Sidekiq::Worker
  sidekiq_options lock: :until_executed, on_conflict: :reject, unique_args: -> (*args) { args }
end

class HeartbeatWorker < UniqueWorker
  sidekiq_options queue: :default, retry: false, backtrace: true
  
  def perform(a, b)
    MyClass.do_some(a, b)
  end
end

Additional context
Currently, gem version is 6.0.22, also we tried to 7.0.0.beta22 and received the same issue.

@0xCCD
Copy link

0xCCD commented Jun 29, 2020

Same problem for me !

@dkirilenko
Copy link

I have the same issue! Any ideas?

@mhenrixon
Copy link
Owner

Seems like a problem with generating the lock.

In v7, you can configure lock_info which for instance would tell you which arguments are configured for uniqueness. Maybe that will help with debugging the issue?

I don't see anything apparently wrong but I suspect you have a problem with the unique arguments and what actually ends up with the worker somehow.

@adrianotadao
Copy link

I'm having the same problem. Any solution?

@mhenrixon
Copy link
Owner

mhenrixon commented Jan 16, 2021

@adrianotadao @0xCCD @migalenkom do any of you create one background job from another?

In the original issue description it looks like that is what is going on. To be completely honest, I haven't done a whole lot of experimenting with this. I just assumed it will work as normal.

The issue description doesn't make clear if this is the case; hence the question.

Ah, now I see that we are doing worker inheritance.

I'll experiment with this. The question remains, do you use either inheritance or scheduling one job from another?

@mhenrixon mhenrixon pinned this issue Jan 22, 2021
@mhenrixon mhenrixon unpinned this issue Jan 22, 2021
@mhenrixon
Copy link
Owner

It would be brilliant if someone that is having this problem could follow the instructions in #571 and create a failing example for me using v7.0.1. I'll close this for now but I'm here to help (preferably with v7).

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants