Ruby’s dynamic nature is both its advantage and disadvantage. Being able to reopen system classes during runtime, while useful, can also lead to unexpected behaviors. This article presents one such case: how just requiring a gem can mess things up in a completely different area of the application.
The bizzare error
Recently, after connecting the Diffend monitor into one of my systems, it started reporting a bizarre error:
uninitialized constant Whenever whenever-1.0.0/lib/whenever/numeric.rb:3:in `respond_to?' lib/ruby/2.7.0/bundler/settings.rb:368:in `==' lib/ruby/2.7.0/bundler/settings.rb:368:in `==' lib/ruby/2.7.0/bundler/settings.rb:368:in `converted_value' lib/ruby/2.7.0/bundler/settings.rb:94:in `' lib/ruby/2.7.0/bundler/fetcher.rb:80:in `' lib/ruby/2.7.0/bundler/fetcher.rb:11:in `' lib/ruby/2.7.0/bundler/fetcher.rb:9:in `' diffend-monitor-0.2.36/lib/diffend/build_bundler_definition.rb:18:in `call' diffend-monitor-0.2.36/lib/diffend/execute.rb:22:in `build_definition' diffend-monitor-0.2.36/lib/diffend/execute.rb:12:in `call' diffend-monitor-0.2.36/lib/diffend/track.rb:21:in `start' diffend-monitor-0.2.36/lib/diffend/monitor.rb:42:in `block in '
the line in which it was happening was just a delegation to the Bundler API method:
::Bundler::Fetcher.disable_endpoint = nil
and in Bundler itself it is just an
class << self attr_accessor :disable_endpoint, :api_timeout, :redirect_limit end
So what does all of it has to do with the Whenever gem? Nothing.
We have nothing to do with Whenever but it does not mean Whenever has nothing to do with us.
Requiring a gem does not only mean that its code is being loaded. It also means that the gem can perform any operations it wants, whether legit or malicious.
diffend-monitor is being required, it spins up its own Ruby thread and starts reporting data. And here is the moment when Whenever kicks in. It was being required after the monitor. Thus the monitor code was already running. In theory, those two should be separated entirely. Whenever and Diffend do entirely different things and they have their own namespaces.
It turns out, unfortunately, that Whenever is monkey patching
Numeric class in an incorrect way:
Numeric.class_eval do def respond_to?(method, include_private = false) super || Whenever::NumericSeconds.public_method_defined?(method) end def method_missing(method, *args, &block) if Whenever::NumericSeconds.public_method_defined?(method) Whenever::NumericSeconds.new(self).send(method) else super end end end
This patch seems to be safe, but there’s a really big assumption made:
Whenever::NumericSeconds needs to be accessible. If we look into the Whenever code loading file, we will notice, that the patch is required before
Whenever::NumericSeconds comes to existence:
require 'whenever/numeric' require 'whenever/numeric_seconds'
This means that any action that would invoke
#method_missing after the first file is loaded, but before the second one, will fail.
Can it even happen? Absolutely! Ruby’s require is not blocking. It means, that Ruby VM can stop the requiring after any of the files and switch context to do other things in other threads.
When the above is understood, building a reproduction code is just a matter of seconds:
Thread.new do while true begin 1.respond_to?(:elo) sleep 0.00001 rescue => e p e end end end sleep 0.2 require 'whenever'
Here’s how it behaves when executed:
I’ve created an issue in Whenever, and hopefully, its maintainers will address it. Meanwhile there’s one more question to ask: can we somehow address this problem, so it won’t break our code?
Mitigating the issue before the library is patched
There is no silver bullet for this type of problem. As any gem can introduce their own patches to other classes, the potential problems are endless. In this particular case, the code ends up being “ok” once everything is loaded. What we’ve decided to do was pretty trivial. We’ve decided to give the app enough time to require all the things that could potentially break the execution:
Thread.new do sleep 0.5 while true begin 1.respond_to?(:elo) sleep 0.00001 rescue => e p e end end end
This sleep ensures that as long as nothing heavy happens during gems requirement via Bundler, we don’t end up with partially loaded, broken monkey-patches while executing our own logic in a background thread.
Cover photo by Ruin Raider on Attribution-NonCommercial-NoDerivs 2.0 Generic (CC BY-NC-ND 2.0) license.