Jobs scheduled to run in the future never run in ActionDispatch::IntegrationTests #846
Comments
|
It's weird that the behavior is different between Could you try doing something like this in the def setup
(ActiveJob::Base.descendants + [ActiveJob::Base]).each(&:disable_test_adapter)
endI think that would cause Rails to respect the queue_adapter assignment. Edit: and to clarify, if the queue adapter is |
|
Sorry for the delayed reply, I could've sworn I replied earlier but I must've forgot to hit post. We're using this line in our test setup to workaround the issue - Seeing as this seems to be an issue with rails, would you like this issue kept open to track the other or would you like me to close it? |
|
Unfortunately, both of your workaround suggestions make the issue worse for me:
|
|
Can you share the code at Would you be able to share your codebase with me? I think it will be tough to debug otherwise. |
|
One of the tests that trigger this error is this one: class AccountControllerTest < ActionDispatch::IntegrationTest
include Devise::Test::IntegrationHelpers
def setup
(ActiveJob::Base.descendants + [ActiveJob::Base]).each(&:disable_test_adapter)
@new_user = {
email: "[email protected]",
subdomain: "testuser",
password: "testpassword",
password_confirmation: "testpassword"
}
end
test "create user and send confirmation and reminder email" do
assert_emails 1 do
assert_difference("User.count") do
post user_registration_url, params: {
user: @new_user
}
end
end
assert_redirected_to account_overview_path
email = ActionMailer::Base.deliveries.last
assert_equal [@new_user[:email]], email.to
assert_emails 1 do
assert_enqueued_with(
job: SendAccountConfirmationReminderJob,
args: [{user_id: User.find_by(email: @new_user[:email]).id}],
queue: "test_accounts",
priority: 5
)
travel(Devise.confirm_within - 3.days) do
GoodJob.perform_inline
end
end
end
endWith (I am very thankful for your help with this! I'd prefer not to share the full codebase though. But I'm happy to share other specific parts that can help debug.) |
|
Thanks! Can you tell me which line in the above code triggers |
|
Yes, I wrapped everything in a begin-rescue-end and asked for the backtrace on the raised exception. And here it is: Thank you for investigating. The last caller appears to be the |
|
@amo13 ohh, the issue here is that you're using test helpers that rely upon the Active Job If you're doing "integration testing" using a real queue adapter like GoodJob, any test helpers relying on the Active Job I think I'd be ok if the GoodJob Adapter quacked like a TestAdapter and implemented |
|
Thank you so much. I am still very new to rails. |
|
ah gotcha. The problem you're experiencing is that you're combining two different integration test strategies that aren't compatible.
Using the second strategy, here is how I would test it: class AccountControllerTest < ActionDispatch::IntegrationTest
include Devise::Test::IntegrationHelpers
def setup
(ActiveJob::Base.descendants + [ActiveJob::Base]).each(&:disable_test_adapter)
@new_user = {
email: "[email protected]",
subdomain: "testuser",
password: "testpassword",
password_confirmation: "testpassword"
}
end
test "create user and send confirmation and reminder email" do
post user_registration_url, params: {
user: @user_data
}
assert_redirected_to account_overview_path
user = User.last
assert_equal @new_user.email, user.email
invite_email = ActionMailer::Base.deliveries.last
assert_equal [@new_user[:email]], invite_email.to
assert_equal "Welcome!", invite_email.subject
travel(Devise.confirm_within - 3.days) do
GoodJob.perform_inline
end
reminder_email = ActionMailer::Base.deliveries.last
assert_equal [@new_user[:email]], reminder_email.to
assert_equal "Don't forget to confirm!", reminder_email.subject
end
end |
|
Thank you very much! I think I begin to understand.
For me, that would be awesome. Making a GoodJob TestAdapter class inheriting from the actual GoodJob adapter and implementing these methods might prevent the confusion. One could then for example declare something like |
|
^ I have rails/rails#48585 in progress to fully solve this issue. And rails/rails#48599 as a smaller PR that should resolve the inability to use |
|
The PR from @ghiculescu is merged and included in Rails 7.2 - I think this should resolve this issue? I just stumbled upon changed job behaviour in my tests when upgrading Rails, which made some tests fail, which is how I noticed this 🙂 Thank you for fixing that! |
For some reason there is different behavior for tests that subclass
ActiveSupport::TestCasevsActionDispatch::IntegrationTest. Any jobs that are run using perform_later are never executed for integration tests (perform_now is unaffected). I admit that running a background job directly in an integration test doesn't make much sense, that was just the most terse way to reproduce the issue.Platform/versions
Ubuntu 22 via WSL 2 on Windows 10
Ruby 2.6.5
Rails 6.1.5.1
GoodJob 3.0.0/3.12.1 (occurs on both)
Steps to Reproduce:
For the code above, the NormalUnitTest test will fail because of the undefined method, while the ActionDispatchIntegrationTest test will finish without ever executing the job.
Observations
I think the root of this issue comes down to different queue adapters being set in the different tests, the normal tests use the GoodJob adapter while the integration tests use the stock ActiveJob adapter. When checking
ActiveJob::Base.queue_adapterin each test:ActiveSupport::TestCasehas an<ActiveJob::QueueAdapters::GoodJobAdapter>instanceActionDispatch::IntegrationTesthas an<ActiveJob::QueueAdapters::TestAdapter>instanceWhen I inspect the queue adapter for the integration test it shows that all the jobs are queued up, but GoodJob can't find them when it goes to execute all pending jobs.
Related
#435 - It looks like a similar (same?) issue came up before, but it was closed without the underlying bug being fixed
rails/rails#37270 - linked in #435, this may actually be a rails issue instead of a GJ issue? I'm not familiar enough with how the queue adapter gets setup to say if this is Rails clobbering GoodJob, or GoodJob not setting itself up properly in certain conditions. I can look into it further if this is accepted as an issue but I wanted to see if this was already a known behavior.
The text was updated successfully, but these errors were encountered: