fix: map headers only when not falsy

[salzig]

tried the faraday.response :logger, failed to me cause headers was nil.

[mislav]

Thanks. But, in which case are headers nil?

[salzig]

I've no clue, but run into it. :)

[sbleon]

@salzig please add a test case demonstrating the problem.

Also, which adapter are you using?

[mislav]

Closing as stale. There is no substantial evidence that this is a bug with Faraday; at least no other people are reporting it.

[kilink]

I saw the same error when I tried doing the following:

conn = Faraday.new(:url => 'http://httpbin.prg') do |faraday|
  faraday.response :logger
end
conn.get('/get') # throws NoMethodError: undefined method `map' for nil:NilClass

Specifying the adapter in the config block resolved the issue:

conn = Faraday.new(:url => 'http://httpbin.prg') do |faraday|
  faraday.response :logger
  faraday.adapter Faraday.default_adapter
end

Perhaps it was a mistake on my end to expect that to be able to only configure response logging there?

[mislav]

When specifying a block to Faraday.new, you always need to explicitly specify an adapter, since none will be chosen for you.

[kilink]

Yeah, that's what I figured out via trial and error, but maybe this is what caused the issue for @salzig as well?

Would it make sense to have a safety belt, so that if the user passes in a block and doesn't configure the adapter, an exception is thrown? It would be more intuitive than having http calls fail inside the logging code because of the nil headers issue.

[mislav]

Would it make sense to have a safety belt, so that if the user passes in a block and doesn't configure the adapter, an exception is thrown?

That would make more sense. However, currently it's not possible to detect whether an adapter has been added to the middleware stack or not. That makes raising a helpful exception a harder problem.

[salzig]

why is there a hard requirement to specify a adapter when using the block notation?
(haven't used faraday for a while)

[iMacTia]

@salzig situation is more or less like this:

• We need an adapter in the stack to perform the call.
• There should be only one adapter in the stack (or the call will be performed multiple times)
• The adapter must be always the last one in the stack (for the way the stack is built)

Now, if you add to this the impossibility for us to detect the adapter at the moment, you'll see there's no safe way to "fix" a malformed stack provided by the user (e.g. missing the adapter).
However, this is being discussed in #121 and #685 if you want to keep an eye on it.
It will probably be an exclusive feature of Faraday v1.0