Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Add integration for GoodJob #453

Closed
olivier-thatch opened this issue Jan 18, 2024 · 4 comments · Fixed by #464
Closed

Add integration for GoodJob #453

olivier-thatch opened this issue Jan 18, 2024 · 4 comments · Fixed by #464

Comments

@olivier-thatch
Copy link
Contributor

GoodJob is an alternative ActiveJob backend similar to Sidekiq and Resque.

I wanted to add an integration for GoodJob, but ran into an annoying issue: GoodJob uses Postgres as its data store, and job-iteration's test harness uses a MySQL database. So in order to be able to test it, I'd need to either switch everything to Postgres, or set up multiple databases.

Because neither of these options were very enticing, I opened a PR in GoodJob's own repository (here), but the maintainer understandably would prefer the integration to live in job-iteration's codebase.

How would you recommend I approach this? Would you be okay with switching the test database from MySQL to Postgres?

@Mangara
Copy link
Contributor

Mangara commented Jan 23, 2024

It makes sense to me to have the interruption adapter code live inside job-iteration. We want the gem to "just work" with major queue adapters, and the interruption adapters don't tend to change very much.

To test this one, we can add a Postgres database that is used to run the GoodJob tests. I'm not a fan of switching the database, as we primarily run MySQL at Shopify, so we want to keep testing especially the Active Record enumerators against that to make sure they don't break silently.

@olivier-thatch
Copy link
Contributor Author

olivier-thatch commented Feb 8, 2024

Hello,

We ended up using the following integration in our codebase:

module JobIteration
  module Integrations
    module GoodJob
      class << self
        attr_accessor :stopping

        def call
          @stopping ||= T.let(false, T.nilable(T::Boolean))
          @stopping
        end
      end
    end

    ActiveSupport::Notifications.subscribe("scheduler_shutdown_start.good_job") do
      JobIteration::Integrations::GoodJob.stopping = true
    end

    JobIteration.interruption_adapter = JobIteration::Integrations::GoodJob
  end
end

Basically, we simply listen to the ActiveSupport notification sent by GoodJob on shutdown (here).

I wanted to submit this as a PR, however writing automated tests for this turned out to be quite complex: not only does GoodJob require a PostgreSQL database as mentioned in my first message, it also requires an actuals Rails app (there are multiple references to Rails.application in its codebase). I did make an attempt at adding a dummy Rails app to job-iteration's test suite, but in the end it proved to be too much work, especially compared to the work involved in writing the actual integration (it is quite trivial). Hopefully someone more familiar with job-iteration's codebase and test suite will be able to write automated tests.

@Mangara
Copy link
Contributor

Mangara commented Feb 21, 2024

I'd still be open to a PR that adds this integration. I'd rather have an integration without tests than no integration at all, especially if you're actively using it.

@olivier-thatch
Copy link
Contributor Author

@Mangara I opened a PR: #464

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

Successfully merging a pull request may close this issue.

2 participants