-
Notifications
You must be signed in to change notification settings - Fork 67
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
Determine a "better solution" for avoiding workers in the Rails console #118
Comments
Hi @mattbnz
3 seems like the most reasonable to me, given that an initializer can be created with the current generator and the experience remains largely the same without running in console surprises Thoughts? other options? |
Option 3 definitely seems the most attractive of those options, and is in-line with my experiences with other job queues which usually have to be explicitly started. Sorry for not thinking about the test/benchmark use-cases up front, seems blatantly obvious in hindsight :) Do you have a plan for how to do option 3 already, or would you welcome a PR with some thoughts? Thanks. |
Happy to accept a PR |
should have a proper solution for this in a coming release, but I figured you can use |
Thanks, sorry I haven't got to this - it pops up in my inbox every weekend for my TODO list and I've been punting it out another week every time as other things take priority... I look forward to seeing how you've solved it. |
PR#99 merged a feature to prevent workers from running in the Rails console, but that was then disabled in later commits 0902676 and d191fb3 without much detail.
This bug is to track getting some details on what a "better solution" might look like - aka what was the issue encountered that required the feature being disabled again, and then the fix.
I'm happy to do some more work on this, but need details on what you'd like to see as the behaviour here.
The text was updated successfully, but these errors were encountered: