Remove Sidekiq::Testing.inline! #3495
Comments
Compelling pitch. I have never used inline myself, I think because it always had a vague smell to it. Historically there's been two reasons why people have used it outside of testing:
|
Ah, ok, that explains all the usage in config/initializers. I think that's a valid use case. I wouldn't do it, but I get it. Any solution provided here could be mis-used for testing, though, so I don't know how would satisfy one and not the other. Maybe just a RACK_ENV-based warning. |
Yeah I guess what I'm proposing is the opposite of that warning - using inline! in tests. You could also move |
What about a Side note: Sidekiq needs an explicit API to get the current environment. |
That would definitely be better. Add some wiki stuff about why inline is bad/dangerous in tests, and you're probably set. |
This is an absolutely horrible idea! I'm trying to get I'm working on a codebase that has exactly the nightmare scenario described here (ActiveRecord callbacks spawning Sidekiq jobs), and I can't tell if the callbacks even work in development unless I run the whole Sidekiq server locally (and if an error happens in the Sidekiq server, it'll be very difficult to debug)! There isn't even a way to do something like |
@mperham Just chiming in to state I personally like what you proposed. FWIW, my use cases with inline are:
Apart from that, yes, the use of ActiveRecord callbacks are one of the biggest pains faced by the "maintainer jumping on an unknown codebase", sadly |
We use the block form of Example: Sidekiq::Testing.inline! do
WorkerThatSpawnsOtherJobs.drain
end |
Is someone interested in providing a PR which logs inline job runs with timing? I don't want to remove APIs at this point but more information (even at DEBUG level) would be useful. |
That is development/architecture fault of this user. Why we should remove Sidekiq functionality due to this "issue" ? Please leave |
Its arguably not "full" integration if you don't push the work to Redis and run them from a Sidekiq worker process. |
Using inline! in development is super handy. I haven't tried using it in my actual tests but after reading the wiki it does seem like the first approach of using drain is a bit more comprehensive. |
I vote for leaving it in: it is useful in both dev and tests. |
Something similar to the warning that was added in Sidekiq 5 re: job size arguments would work.
I still advocate for the original solution of Sidekiq::Development.inline! API + removing the support for block-less Sidekiq::Testing.inline!. |
We have 5 years of codebases using Sidekiq and I don't want to break APIs without a clean, documented migration path and a very good reason. Are there specific changes anyone recommends and would be willing to prototype? Without a specific proposal, I'm going to close this issue; we all agree -- "this could be better" -- but what is better enough to justify the migration pain? |
When in doubt, don't poke a sleeping bear. Too much inertia here so we'll leave it alone. |
Semi-troll incoming! I realize this is unlikely, but wanted to get your thoughts.
I propose that Sidekiq::Testing.inline! is almost entirely misused, and just allows people to write slow, lazy tests.
The nightmare scenario is this: user puts Sidekiq jobs into ActiveRecord callbacks, then uses something like
factory_girl
and creates hundreds of records and thus sidekiq jobs on every test. There is no feedback that tons of Sidekiq jobs are being executed besides the tests being slow. Now the user's unit tests take minutes to complete.Now, before you say "oh that's just a dumb user, provide sharp tools, etc etc" just look at how people actually use
inline!
.Is there any use-case for
inline
which cannot be replaced bySomeWorker.drain
?Proposals:
inline
is used, provide some logger feedback that jobs are being executed, and maybe how long they're taking. Sort of like the feedback provided when usingdelay
on instance methods.inline
testing entirely.inline!
method and only allow the block form of inline, which should eliminate some of it's misuse (though people will still use around blocks I bet)The text was updated successfully, but these errors were encountered: