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

Infer interruption handler from job #96

Conversation

plasticine
Copy link
Contributor

@plasticine plasticine commented May 27, 2021

This was a bit of a quick attempt to fix #90

Firstly I wanted to apologise for the size of this patch, and how disruptive the renaming here is—understand this might be a non-starter for various reasons, but I was keen to use autoloading and the current naming scheme breaks this AFAIK.

Happy to try and rework and open to suggestions on how to proceed here if this patch is otherwise of interest. 🙃

If this patch gets accepted I’ll be very keen to follow up with further patches for #88 & #89.

@plasticine plasticine force-pushed the plasticine/infer-interruption-handler branch from 4ffe632 to 47adc55 Compare May 27, 2021 22:32
…self

Instead of automatically attempting to load the interruption adapter implicitly this patch changes this to be discovered for a given worker based on the job itself based on its class adapter.

I believe this will work OK, and should allow a bit more flexibility around using JobIteration.

This patch also contains a bunch of renames, broadly from  `job-iteration` -> `job_iteration`.

This might be a bit contentious, but the current module naming breaks
autoloading a bit, which is not ideal, and I’d like to leverage it for loading integrations.
@plasticine plasticine force-pushed the plasticine/infer-interruption-handler branch from 47adc55 to fc68076 Compare June 2, 2021 23:39
@plasticine
Copy link
Contributor Author

Hey all 👋 — rebased this again, but keen to hear feedback on whether this patch is desirable or not. Very keen to try and get job-iteration into a state where we can use it, so happy to rework this into something that will be merged if needs be.

@plasticine
Copy link
Contributor Author

Hey @sambostock @adrianna-chang-shopify 👋 Sorry for a ping on this directly, but I’d be really interested in some feedback here if either of you has a moment (or can redirect this in a better direction).

@adrianna-chang-shopify
Copy link
Contributor

Hey @plasticine !

I'll nudge @GustavoCaso and @Mangara from our Jobs team -- they probably have more context on potential consequences to inferring the integration from the queue adapter inside the iteration code, instead of setting it up front based on what integration can be loaded.

It's a little hard to parse the diff because of the rename -- maybe that could get split into a separate commit up front, with the changes to the integration code committed separately?

@Mangara
Copy link
Contributor

Mangara commented Jul 13, 2021

It's a little hard to parse the diff because of the rename -- maybe that could get split into a separate commit up front, with the changes to the integration code committed separately?

I'd prefer a separate PR even.

Comment on lines +7 to +10
extend ActiveSupport::Autoload

autoload :SidekiqIntegration
autoload :ResqueIntegration
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For what it's worth, this could just use Ruby's built-in autoloading, which wouldn't require the rename.

Suggested change
extend ActiveSupport::Autoload
autoload :SidekiqIntegration
autoload :ResqueIntegration
autoload :SidekiqIntegration, "#{__dir__}/integrations/sidekiq_integration.rb"
autoload :ResqueIntegration, "#{__dir__}/integrations/resque_integration.rb"

From there, a separate PR could propose the rename and use of ActiveSupport::Autoload, though I'm not sure there is much benefit, since the autoloading is so limited.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Argh — I didn’t even consider this, thanks

@plasticine
Copy link
Contributor Author

Hey all, thanks very much for the feedback, and apologies again for the messiness of this patch — it got a bit out of hand as I was hacking around. 🙃

How does the core idea of inferring the integration strike y’all?—If that’s palatable then I’ll rework this patch into something a little less unwieldy without the renaming.

@Mangara
Copy link
Contributor

Mangara commented Jul 14, 2021

How does the core idea of inferring the integration strike y’all?

It makes sense to me.

@adrianna-chang-shopify
Copy link
Contributor

Makes a lot of sense to me too - since Rails supports specifying the queue adapter on a per-job basis, it seems unnecessarily inflexible to force Job Iteration users to stick to a single queuing backend for their whole application.

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 this pull request may close these issues.

Support multiple present background worker implementations
4 participants