`any?` wrong number of arguments upon upgrading 1.10.0 -> 1.11.1

[PatrickatPaperlessPCS]

I have a rails app that I've used Capistrano to deploy with several times. I did a fairly major update on the app that included an update of Capistrano-rails from 1.1.6 to 1.1.7 and SSHkit from 1.10.0 to 1.11.1. Now my cap production deploy fails with what seems like an sshkit issue.

Here's my error output:

** Invoke deploy:check (first_time)
** Execute deploy:check
** Invoke git:check (first_time)
** Invoke git:wrapper (first_time)
** Execute git:wrapper
00:00 git:wrapper
      01 mkdir -p /tmp/dentalimager/
cap aborted!
ArgumentError: wrong number of arguments (0 for 1)
/home/patrick/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/capistrano-3.5.0/lib/capistrano/dsl/env.rb:16:in `any?'
/home/patrick/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sshkit-1.11.1/lib/sshkit/host.rb:84:in `block in netssh_options'
/home/patrick/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sshkit-1.11.1/lib/sshkit/host.rb:83:in `tap'
/home/patrick/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sshkit-1.11.1/lib/sshkit/host.rb:83:in `netssh_options'
/home/patrick/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/capistrano-3.5.0/lib/capistrano/configuration/server.rb:59:in `netssh_options'
/home/patrick/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sshkit-1.11.1/lib/sshkit/backends/netssh.rb:159:in `with_ssh'
/home/patrick/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sshkit-1.11.1/lib/sshkit/backends/netssh.rb:108:in `execute_command'
/home/patrick/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sshkit-1.11.1/lib/sshkit/backends/abstract.rb:141:in `block in create_command_and_execute'
/home/patrick/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sshkit-1.11.1/lib/sshkit/backends/abstract.rb:141:in `tap'
/home/patrick/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sshkit-1.11.1/lib/sshkit/backends/abstract.rb:141:in `create_command_and_execute'
/home/patrick/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sshkit-1.11.1/lib/sshkit/backends/abstract.rb:74:in `execute'
/home/patrick/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/capistrano-3.5.0/lib/capistrano/tasks/git.rake:16:in `block (3 levels) in <top (required)>'
/home/patrick/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sshkit-1.11.1/lib/sshkit/backends/abstract.rb:29:in `instance_exec'
/home/patrick/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sshkit-1.11.1/lib/sshkit/backends/abstract.rb:29:in `run'
/home/patrick/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/sshkit-1.11.1/lib/sshkit/runners/parallel.rb:12:in `block (2 levels) in execute'
Tasks: TOP => git:check => git:wrapper
The deploy has failed with an error: wrong number of arguments (0 for 1)
** Invoke deploy:failed (first_time)
** Execute deploy:failed

See this question on stackexchange also

Update:

I switched back to 1.10.1 globally and worked around the problem for now

[mattbrictson]

@xavierholt Looks like we have a bug where @keys is somehow not an Array (maybe nil?) in an instance of SSHKit::Host. I think this has surfaced due to the changes you made in #350. Any ideas what is happening here?

[mattbrictson]

Crash happens here: https://github.com/capistrano/sshkit/blob/v1.11.1/lib/sshkit/host.rb#L84

[mattbrictson]

@PatrickatPaperlessPCS are you setting key or keys in any of your server configurations in your production.rb?

[xavierholt]

@mattbrictson: It's possible that someone's using Host#keys= with something that's not an array... I'm not convinced that's it, though. Do we have a minimal example? I'm going to look at the Ruby docs for #any? in the meantime, see if I can find anything suspicious.

[xavierholt]

Found it. Whatever object is stored as @keys implements Capistrano::DSL::Env#any?, which requires an argument. Offhand I'd say that it doesn't make sense to have an Env stored as keys, but if I'm wrong I messed up big time!

https://github.com/capistrano/capistrano/blob/master/lib/capistrano/dsl/env.rb#L16

[PatrickatPaperlessPCS]

@mattbrictson No, I dont have any keys in production.rb or server configs.

[mattbrictson]

@xavierholt Right, it is Capistrano::DSL::Env#any?. That's because DSL is mixed into all Ruby objects. So nil.any? will cause this error, as will "foo".any? or any object that doesn't already have its own any? method (as Array does).

The big question is why is @keys not an Array?

Before #350 was merged, we had this:

def keys
  Array(@keys)
end

So that effectively protected us from @keys being nil or non-Array, since:

Array(nil) # => []
Array("foo") # => ["foo"]

The brute force fix is therefore to restore that Array() wrapper, but that still doesn't explain why @keys is being set to something other than an Array in the first place.

I'm stumped!

[mattbrictson]

@PatrickatPaperlessPCS Can you run cap production doctor and paste the output here? Be sure to redact any sensitive usernames, IP addresses, or passwords that you don't want us to see. Thanks!

[xavierholt]

Oh - didn't realize that was mixed into all objects; thought it was a clue as to what was getting assigned there.

I support the brute force fix. There's no type checking on #keys=, so it'd be pretty easy to assign a non-enumerable there by accident. Does seem indicative of a bug somewhere, though... Tried to reproduce locally but no luck.

[mattbrictson]

@xavierholt If you would like to propose a PR with the brute force fix, I will merge it in.

@PatrickatPaperlessPCS I'd still like to see your cap production doctor output when you have a chance, so that we can get to the bottom of this issue.

Thank you both!

[mattbrictson]

Haven't heard back from the OP, so I will consider this fixed by #359.