Reset passwords instructions is not being sent

[elpic]

The reset password instructions generate a token, after that token is generated a commit happened so the method send_devise_pending_notifications is called and the list of pending notifications is empty. After that the send_devise_notification is called and added a pending notification but that notification is never being sent.

[baschtl]

@elpic Is this still an issue for you? If so, I need a bit more information here. It's hard to guess what might be going wrong. What is your setup/configuration?

[elpic]

Hi @baschtl,

Yes is still an issue, I workarounded by saving the user on the reset password controller after the send_reset_password_instructions method is being called.

devise-async (0.9.0)
devise (3.4.1)

What other information do you need?

Thanks

[baschtl]

What backend are you using with devise async? When your backend wants to process the email and deliver it, does it throw an exception?

[elpic]

I'm using sidekiq

[elpic]

No, it don't. What is happening is that the queue keep one element on it, and because the object is never saved after the element is added to the queue the mail was never being sent.

[baschtl]

Have you tried https://github.com/mhfs/devise-async#troubleshooting ?

[elpic]

Yes, I've tried that.

Also after I save manually the model (by overwriting the controller) the email is being sent.

[baschtl]

Hmm, ok. Then I am a bit out of ideas...

[volkanunsal]

Same problem here.

[maia]

I've encountered a similar error (not sending invitation mails usinge devise_invitable) and managed to trace it back to my self rolled unique jobs middleware, loosely based on Sidekiq 2.0.4 (before it was moved to pro/enterprise only). Sidekiq will run middleware.invoke(worker_class, item, queue, @redis_pool) and usually item['args'].first is a Hash with job_class and arguments as keys. In the case of devise_invitable item['args'].firstis only a symbol, which caused an error in my middleware.

I've not managed to understand why the format of item is different, but I was able to add a check in my middleware.

@baschtl , is it possible this is related?

I'm running devise (3.5.5), devise-async (0.10.1), devise_invitable (1.5.5) and sidekiq (4.0.2).

Here is my traceback:

File "/app/vendor/bundle/ruby/2.2.0/gems/sidekiq-4.0.2/lib/sidekiq/middleware/chain.rb" line 129 in block in invoke
File "/app/vendor/bundle/ruby/2.2.0/gems/sidekiq-4.0.2/lib/sidekiq/middleware/chain.rb" line 132 in call
File "/app/vendor/bundle/ruby/2.2.0/gems/sidekiq-4.0.2/lib/sidekiq/middleware/chain.rb" line 132 in invoke
File "/app/vendor/bundle/ruby/2.2.0/gems/sidekiq-4.0.2/lib/sidekiq/client.rb" line 203 in process_single
File "/app/vendor/bundle/ruby/2.2.0/gems/sidekiq-4.0.2/lib/sidekiq/client.rb" line 65 in push
File "/app/vendor/bundle/ruby/2.2.0/gems/sidekiq-4.0.2/lib/sidekiq/worker.rb" line 100 in client_push
File "/app/vendor/bundle/ruby/2.2.0/gems/sidekiq-4.0.2/lib/sidekiq/worker.rb" line 54 in perform_async
File "/app/vendor/bundle/ruby/2.2.0/gems/devise-async-0.10.1/lib/devise/async/backend/sidekiq.rb" line 10 in enqueue
File "/app/vendor/bundle/ruby/2.2.0/gems/devise-async-0.10.1/lib/devise/async/worker.rb" line 11 in enqueue
File "/app/vendor/bundle/ruby/2.2.0/gems/devise-async-0.10.1/lib/devise/async/model.rb" line 43 in send_devise_notification
File "/app/vendor/bundle/ruby/2.2.0/gems/devise_invitable-1.5.5/lib/devise_invitable/model.rb" line 170 in deliver_invitation
File "/app/vendor/bundle/ruby/2.2.0/gems/devise_invitable-1.5.5/lib/devise_invitable/model.rb" line 134 in invite!
File "/app/vendor/bundle/ruby/2.2.0/gems/devise_invitable-1.5.5/lib/devise_invitable/model.rb" line 278 in _invite
File "/app/vendor/bundle/ruby/2.2.0/gems/devise_invitable-1.5.5/lib/devise_invitable/model.rb" line 283 in invite!

[baschtl]

@maia I currently do not have the time to investigate deeply... Do you have a minimal setup that I could use to investigate further?

[maia]

@baschtl I've compared the arguments and notices that it's caused by a different handling of ActiveJob and 'native' Sidekiq jobs:

When calling a random ActiveJob which is using Sidekiq, this is what gets sent to the Sidekiq Client Middleware:

    worker_class = "ActiveJob::QueueAdapters::SidekiqAdapter::JobWrapper"
    item         = { "class"      => "ActiveJob::QueueAdapters::SidekiqAdapter::JobWrapper",
                     "wrapped"    => "RandomNamedJob",
                     "queue"      => "low_priority",
                     "args"       => [
                         { "job_class"  => "RandomNamedJob",
                           "job_id"     => "b9b47d6a-1e3b-4070-86cf-ef9390f80127",
                           "queue_name" => "low_priority",
                           "arguments"  => [],
                           "locale"     => :en
                         }],
                     "retry"      => true,
                     "jid"        => "99c01e47ac07cc2458cf4989",
                     "created_at" => 1454451127.645387 }
    queue        = "low_priority"

Whereas devise_invitable which directly calls Sidekiq will send:

    worker_class = "Devise::Async::Backend::Sidekiq"
    item         = { "class"      => "Devise::Async::Backend::Sidekiq",
                     "args"       => [
                         :invitation_instructions,
                         "User",
                         "37",
                         "U9zqqzQY4Ch2zo8V9isg",
                         {}
                     ],
                     "retry"      => true,
                     "queue"      => "mailers",
                     "jid"        => "799c461a00f9566ba10ad5ac",
                     "created_at" => 1454451250.7714372 }
    queue        = "mailers"

As you can see, in case of ActiveJob the item["args"] array contains a single hash, whereas for Sidekiq jobs the array contains the arguments itself. When using a middleware expecting one or the other, it will fail.

This might not be the cause of the others seeing invitations not being sent, but I thought I'd mention it here as such issues are hard to trace.

[guigs]

I think this is the same problem described by @mrnugget in #52 (comment). He also proposes a solution.

[JWesorick]

Is this still an issue? If I use this gem does it not work with sending reset password emails?