Sam Bostock

👋 I was going to open a new issue, but this seemed like a more appropriate place to chime in. ---- **TL;DR: Lack of support for custom enumerators prevents certain...

As per the discussion in https://github.com/Shopify/maintenance_tasks/pull/307#discussion_r561420323, I'm going to expand on some of our use cases, with respect to processing API resources in Twilio. Most of these tasks run on...

Thanks for the reviews @adrianna-chang-shopify & @etiennebarrie! ---- > Could we also add a section to the README for this feature? I would document it at the bottom in its...

@adrianna-chang-shopify another alternative I considered was to simply have two different classes one could inherit from, which have different APIs: one has `enumerator` "not implemented", and the other implements it...

@adrianna-chang-shopify how do you see that being used compared to a standard `Task` within the framework? Would we keep the logic in `TaskJob`? ```ruby def build_enumerator(_run, cursor:) cursor ||= @run.cursor...

> We should not use inheritance when what we want is to change strategy. Use the strategy pattern please. Interesting point @rafaelfranca. One difficulty I see is that the interface...

@rafaelfranca your idea is indeed pretty similar to #307, though I had chosen `.call` so that simple cases could use a `proc` or `lambda`. It's not much work for consumers...

Lots of moving pieces across the refactors. 😅 Thanks for catching the various things I missed @adrianna-chang-shopify!

Isn't this already possible by calling [`queue_as`](https://api.rubyonrails.org/classes/ActiveJob/QueueName/ClassMethods.html#method-i-queue_as) on the job class? Seems to be `public`. ```ruby MaintenanceTasks::TaskJob.queue_as(...) { ... } ``` Though maybe we want an interface that just forwards...

Yeah, I was trying to come up with something elegant, but it really breaks down if we don't know the job class ourselves. I think documenting `queue_as`, and then documenting...