KeyError: key not found: :status

[Vpatel1093]

Running into this error after upgrading from 2.13.1 to 2.13.2

Seems related to this: https://github.com/lostisland/faraday/pull/1628/files#diff-c5f031a4be2bbda4d7befb7c1604ffee77d3bc86038f280aca9b14f1fc00350e

App code:
MyClient.new.create_user(sign_up_data)

class MyClient
    attr_reader :base_url

    def initialize(base_url)
      @base_url = base_url
    end

    def create_user(params)
      connection.post('registrations', params)
    end

    def connection
      @connection ||= build_connection
    end

    private

    # :reek:FeatureEnvy, :reek:TooManyStatements
    def build_connection
      Faraday.new(options) do |config|
        config.use Signature
        config.request :json
        config.response :json, preserve_raw: true
        config.response :raise_error
        config.response :logger, Rails.logger, { bodies: true, headers: true, log_level: :debug }
      end
    end

    def options
      {
        request: {
          open_timeout: 5,
          read_timeout: 15,
          write_timeout: 15
        },
        url: base_url
      }
    end
end

Stacktrace:

KeyError: key not found: :status

  0) RegistrationsController POST reate when Root Central has an error when Root Central has a non-JSON error renders the registration page with a default message
     Failure/Error: RootSDK::RootCentral::Client.new.create_user(sign_up_data)

     KeyError:
       key not found: :status
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/faraday-2.13.2/lib/faraday/error.rb:85:in 'fetch'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/faraday-2.13.2/lib/faraday/error.rb:85:in 'exc_msg_and_response'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/faraday-2.13.2/lib/faraday/error.rb:73:in 'exc_msg_and_response!'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/faraday-2.13.2/lib/faraday/error.rb:12:in 'initialize'
     > ./app/controllers/registrations_controller.rb:11:in 'create'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/ddtrace-1.23.3/lib/datadog/tracing/contrib/action_pack/action_controller/instrumentation.rb:105:in 'process_action'
     > ./app/controllers/application_controller.rb:15:in 'set_time_zone'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/turbo-rails-2.0.12/lib/turbo-rails.rb:24:in 'with_request_id'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/turbo-rails-2.0.12/app/controllers/concerns/turbo/request_id_tracking.rb:10:in 'turbo_tracking_request_id'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/react-rails-2.7.1/lib/react/rails/controller_lifecycle.rb:31:in 'use_react_component_helper'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/audited-5.8.0/lib/audited/sweeper.rb:16:in 'around'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/audited-5.8.0/lib/audited/sweeper.rb:16:in 'around'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/actiontext-7.0.8.7/lib/action_text/rendering.rb:20:in 'with_renderer'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/actiontext-7.0.8.7/lib/action_text/engine.rb:69:in 'block (4 levels) in <class:Engine>'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/omniauth-2.1.3/lib/omniauth/strategy.rb:202:in 'call!'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/omniauth-2.1.3/lib/omniauth/strategy.rb:169:in 'call'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/rack-attack-6.7.0/lib/rack/attack.rb:127:in 'call'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/exception_notification-4.6.0/lib/exception_notification/rack.rb:49:in 'call'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/warden-1.2.9/lib/warden/manager.rb:36:in 'block in call'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/warden-1.2.9/lib/warden/manager.rb:34:in 'catch'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/warden-1.2.9/lib/warden/manager.rb:34:in 'call'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/rack-2.2.17/lib/rack/tempfile_reaper.rb:15:in 'call'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/rack-2.2.17/lib/rack/etag.rb:27:in 'call'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/rack-2.2.17/lib/rack/conditional_get.rb:40:in 'call'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/rack-2.2.17/lib/rack/head.rb:12:in 'call'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/rack-2.2.17/lib/rack/session/abstract/id.rb:266:in 'context'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/rack-2.2.17/lib/rack/session/abstract/id.rb:260:in 'call'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/ddtrace-1.23.3/lib/datadog/tracing/contrib/rails/middlewares.rb:19:in 'call'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/railties-7.0.8.7/lib/rails/rack/logger.rb:40:in 'call_app'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/railties-7.0.8.7/lib/rails/rack/logger.rb:25:in 'block in call'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/semantic_logger-4.16.1/lib/semantic_logger/base.rb:190:in 'block in tagged'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/semantic_logger-4.16.1/lib/semantic_logger/semantic_logger.rb:356:in 'tagged'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/semantic_logger-4.16.1/lib/semantic_logger/base.rb:202:in 'tagged'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/railties-7.0.8.7/lib/rails/rack/logger.rb:25:in 'call'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/rack-2.2.17/lib/rack/method_override.rb:24:in 'call'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/rack-2.2.17/lib/rack/runtime.rb:22:in 'call'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/rack-2.2.17/lib/rack/sendfile.rb:110:in 'call'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/ddtrace-1.23.3/lib/datadog/tracing/contrib/rack/middlewares.rb:109:in 'call'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/railties-7.0.8.7/lib/rails/engine.rb:530:in 'call'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/rack-test-2.2.0/lib/rack/test.rb:360:in 'process_request'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/rack-test-2.2.0/lib/rack/test.rb:153:in 'request'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/rails-controller-testing-1.0.5/lib/rails/controller/testing/integration.rb:16:in 'block (2 levels) in <module:Integration>'
     > ./spec/requests/registrations_controller_spec.rb:21:in 'block (3 levels) in <main>'
     > ./spec/requests/registrations_controller_spec.rb:89:in 'block (5 levels) in <main>'
     > ./spec/rails_helper.rb:99:in 'block (3 levels) in <top (required)>'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/database_cleaner-core-2.0.1/lib/database_cleaner/strategy.rb:30:in 'cleaning'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/database_cleaner-core-2.0.1/lib/database_cleaner/cleaners.rb:34:in 'block (2 levels) in cleaning'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/database_cleaner-core-2.0.1/lib/database_cleaner/cleaners.rb:35:in 'cleaning'
     > ./spec/rails_helper.rb:99:in 'block (2 levels) in <top (required)>'
     > /Users/root/.rvm/gems/ruby-3.2.8/gems/webmock-3.25.1/lib/webmock/rspec.rb:39:in 'block (2 levels) in <main>'

[iMacTia]

Thank you for raising this @Vpatel1093, and sorry you bumped into it.
It's really strange that the response object doesn't have any status property.

Does this happen in production or during tests?
Also, I see you have the logger middleware in your configuration, could you check if your logs have anything to show about the response? (it should, as being at the bottom of the config it should log the response BEFORE the raise_error middleware raises this exception)

[derekharmel]

I'm seeing a similar problem that I believe is likely caused by @Vpatel1093's issue.

We're using v2.0.1 the zendesk_api gem which is using Faraday. Since the updating Faraday to 2.13.2, we're experiencing a problem in that library's error handling code.

Stacktrace:

/app/vendor/bundle/ruby/3.0.0/gems/zendesk_api-2.0.1/lib/zendesk_api/error.rb:22:in `initialize': undefined method `[]' for nil:NilClass (NoMethodError)
/app/vendor/bundle/ruby/3.0.0/gems/zendesk_api-2.0.1/lib/zendesk_api/middleware/response/raise_error.rb:18:in `new'
/app/vendor/bundle/ruby/3.0.0/gems/zendesk_api-2.0.1/lib/zendesk_api/middleware/response/raise_error.rb:18:in `on_complete'
/app/vendor/bundle/ruby/3.0.0/gems/faraday-2.13.2/lib/faraday/middleware.rb:57:in `block in call'
/app/vendor/bundle/ruby/3.0.0/gems/faraday-2.13.2/lib/faraday/response.rb:42:in `on_complete'
/app/vendor/bundle/ruby/3.0.0/gems/faraday-2.13.2/lib/faraday/middleware.rb:56:in `call'
/app/vendor/bundle/ruby/3.0.0/gems/zendesk_api-2.0.1/lib/zendesk_api/middleware/response/raise_error.rb:8:in `call'
/app/vendor/bundle/ruby/3.0.0/gems/faraday-2.13.2/lib/faraday/rack_builder.rb:153:in `build_response'
/app/vendor/bundle/ruby/3.0.0/gems/faraday-2.13.2/lib/faraday/connection.rb:452:in `run_request'
/app/vendor/bundle/ruby/3.0.0/gems/faraday-2.13.2/lib/faraday/connection.rb:280:in `post'
/app/vendor/bundle/ruby/3.0.0/gems/zendesk_api-2.0.1/lib/zendesk_api/actions.rb:32:in `save!'
/app/vendor/bundle/ruby/3.0.0/gems/zendesk_api-2.0.1/lib/zendesk_api/actions.rb:153:in `block in create!'
<internal:kernel>:90:in `tap'
/app/vendor/bundle/ruby/3.0.0/gems/zendesk_api-2.0.1/lib/zendesk_api/actions.rb:152:in `create!'
/app/vendor/bundle/ruby/3.0.0/gems/zendesk_api-2.0.1/lib/zendesk_api/collection.rb:64:in `block (2 levels) in <class:Collection>'

Relevant code from the zendesk_api library in the stacktrace above:
https://github.com/zendesk/zendesk_api_client_rb/blob/v2.0.1/lib/zendesk_api/error.rb#L22
https://github.com/zendesk/zendesk_api_client_rb/blob/v2.0.1/lib/zendesk_api/middleware/response/raise_error.rb#L18

I did some debugging via monkeypatching in the zendesk_api gem with the following:

module ZendeskAPI
  module Middleware
    class RecordInvalid
      attr_accessor :errors

      def initialize(*args)
        puts "0: #{args.inspect}"
        super

        puts "1: #{response.inspect}"
        if response[:body].is_a?(Hash)
          @errors = response[:body]["details"] || generate_error_msg(response[:body])
        end

        @errors ||= {}
      end
    end
  end
end

The puts 0: printed 0: [#<Faraday::Env @method=:post @request_body="{.... Whereas, the puts 1: printed 1: nil. Therefore something in super is causing the problem and if you trace through the code in the links above the cause has to be in Faraday::ClientError and therefore Faraday::Error. I suspect the recent changes to Faraday::Error#exc_msg_and_response are the problem, but haven't figured out what's happening.

[Vpatel1093]

Thank you for raising this @Vpatel1093, and sorry you bumped into it. It's really strange that the response object doesn't have any status property.

Does this happen in production or during tests? Also, I see you have the logger middleware in your configuration, could you check if your logs have anything to show about the response? (it should, as being at the bottom of the config it should log the response BEFORE the raise_error middleware raises this exception)

@iMacTia This was during tests, we have 2.13.1 in production still. I copied everything that rspec printed out here

[derekharmel]

Just following up to confirm that rolling back to 2.13.1 resolved my problem.

[iMacTia]

OK sorry I didn't have time to look again at this until today, but I think the issue might be that response could be a Struct too. I'll validate this and see if I can push a fix

[iMacTia]

Allright, I could confirm that Struct does indeed respond to #each_key like Hash, meaning the new is_a?(Hash) check is incomplete, I'll address that and ask you both to test if that's OK 🙏

[iMacTia]

I've got a PR (#1630) ready to address this.
@derekharmel @Vpatel1093 would you have some time to pull the PR branch into your project and test if it solves the problem?

[a-lavis]

I've got a PR ready to address this. would you have some time to pull the PR branch into your project and test if it solves the problem?

@iMacTia I was running into the same issue with the zendesk_api gem - when I changed my gemfile to:

gem 'faraday', git: 'https://github.com/lostisland/faraday', branch: 'mg/fix-type-assumption'

that seems to have fixed the bug! thanks for working on the fix!

[iMacTia]

Fantastic! Thank you for confirming @a-lavis, I'll merge and release 👍

[NikosVlagoidis]

After upgrading to Faraday 2.13.3, calling client.users.find(id: 'non_existing_id') with zendesk_api throws:

KeyError: key not found: :method

Root Cause
When the API returns 400 Bad Request, exc.request here is a Faraday::RequestOptions instance that doesn't have a method method, but the error handling code expects it. In that case it should probably be exc.method

Environment
Faraday: 2.13.3
zendesk_api: 3.1.1