Решили мы как-то добавить Rate Limits заголовки к SubscriptionRequiredError ошибкам, чтобы фронт (приложение для подсчета калорий MealUp) понимал, какие именно лимиты и насколько пользователь превысил. Для этого мы стали рендерить эту ошибку с расчётом лимитов для конкретного пользователя - current_user. Перехватывали мы ошибку стандартно:

mealup/app/api/v1/api.rb:

module V1
  class API < Grape::API
    ...
    rescue_from SubscriptionRequiredError, with: :render_error
    ...
    helpers V1::Helpers::ResponseHelpers
    ...

mealup/app/api/v1/helpers/response_helpers.rb:

module V1
  module Helpers
    module ResponseHelpers
      ...
      def render_error(error)
        error = serialize_error(error)
        error!({ error:, with: error_entity(error) }, error.try(:http_status) || 403)
      end

      def serialize_error(error)
        case error
        ...
        when SubscriptionRequiredError
          assign_rate_limit_headers(current_user, error.limit_key) # <- Вот что добавилось
          error
        ...
      end
      ...
          

Казалось бы, что может пойти не так? А вот выясняется, что нету там current_user-а. Более того - там нет даже объекта request, из которого через заголовки мы этого current_user-а и ищем. "Как в апи при обработке запроса может отсутствовать объект запроса", - спросите вы? "Никак", - ответил бы я. И был бы неправ.

Посмотрим поближе, что происходит с DSL Grape, и куда девается наш request. В проекте у нас используется gem 'grape-swagger', который под капотом использует grape 2.2.0. Поэтому обсуждаем эту версию.

:rescue_from метод определяется в Grape::DSL::RequestResponse (lib/grape/dsl/request_response.rb). Там Grape собирает найденные обработчики ошибок и записывает их в InheritableSetting, после чего они будут переданы в Grape::Middleware::Error при инициализации как :options. Записываются они примерно так:

options[:rescue_handlers]
=> {
  ActiveRecord::RecordNotFound=>:render_not_found_error,
  SubscriptionRequiredError=>:render_error,
  Telegram::InvalidSchemeError=>:render_error
}

Когда понадобится обработать ту или иную ошибку, за это возьмется метод Grape::Middleware::Error#run_rescue_handler.

def run_rescue_handler(handler, error, endpoint)
    if handler.instance_of?(Symbol)
      raise NoMethodError, "undefined method '#{handler}'" unless respond_to?(handler)

      handler = public_method(handler) # <- Здесь символ :render_error превратится в объект класса Method
    end
    ...
    

Здесь handler из символа :render_error превращается в объект класса Method:

handler
=> #<Method: #<Class:0x0000000123bf53c8>(V1::Helpers::ResponseHelpers)#render_error(error) .../mealup/app/api/v1/helpers/response_helpers.rb:59>

чуть позже в том же run_rescue_handler будет вызван endpoint.instance_exec(error, &handler), и код возвращается из гема в наш helper, но уже без request и без current_user.

А что если мы чуть пожертвуем красотой в api.rb, и вместо одной строки, будем отлавливать ошибку на трех?

# rescue_from SubscriptionRequiredError, with: :render_error
rescue_from SubscriptionRequiredError do |e|
  render_error(e)
end

На первый взгляд - то же самое. Но вот где кроется отличие:

options[:rescue_handlers]
=> {
  ActiveRecord::RecordNotFound=>:render_not_found_error,
  SubscriptionRequiredError=>#<Proc:0x00000001259eb418 .../mealup/app/api/v1/api.rb:15>,
  Telegram::InvalidSchemeError=>:render_error
}

теперь в методе run_rescue_handler grape не будет подменять наш handler и вызывать public_method(handler). Он возьмет наш блок или лямбду, смотря, как вы определили rescue_from обработчик, и точно также передаст его в endpoint: endpoint.instance_exec(error, &handler). И уже в этом случае мы возвращаемся из гема в наш helper и с объектом request, и с current_user.

Почему же так происходит?

Это уже не особенность Grape, а поведение самого Ruby. Дело в instance_exec, Method, Proc и в том, как они работают с self, от которого зависит, какие методы и данные доступны в момент выполнения. Объект Method - это метод, привязанный к конкретному receiver-у, какому-то объекту. В нем - self всегда будет равным этому объекту. Proc, block и lambda - более гибки в этом вопросе, и выполняются с self, заданным в момент вызова.

Чтобы понять, почему Method теряет контекст, а лямбда — нет, давайте посмотрим на простенький пример. Определим пару классов:

class Middleware
  def greet
    puts "self is: #{self.class}"
    puts "request: #{respond_to?(:request) ? request.inspect : 'NO METHOD request'}"
  end
end

class Endpoint
  attr_reader :request

  def initialize
    @request = "I am the request object"
  end

  def greet
    puts "self is: #{self.class}"
    puts "request: #{respond_to?(:request) ? request.inspect : 'NO METHOD request'}"
  end
end

И создадим их экземпляры:

middleware = Middleware.new
endpoint   = Endpoint.new

Теперь если мы возьмем метод :greet из middleware и применим его в контексте endpoint, как вы думаете, что будет? Увидит ли он @request?

irb(main):123> handler = middleware.public_method(:greet)
#<Method: Middleware#greet() (irb):72>

irb(main):123> endpoint.instance_exec(&handler)
self is: Middleware
request: NO METHOD request
=> nil

А если handler будет лямбдой?

irb(main):125> handler = -> { puts "self is: #{self.class}"; puts "request: #{request.inspect}" }
=> #<Proc:0x000000012509ec98 (irb):125 (lambda)>

endpoint.instance_exec(&handler)
self is: Endpoint
request: "I am the request object"
=> nil

То же самое происходит и в Grape. Когда мы вызываем endpoint.instance_exec(error, &handler), мы вызываем handler в контексте экземпляра Grape::Endpoint:

gems/grape-2.2.0/lib/grape/endpoint.rb:

...
module Grape
  # An Endpoint is the proxy scope in which all routing
  # blocks are executed. In other words, any methods
  # on the instance level of this class may be called
  # from inside a `get`, `post`, etc.
  class Endpoint
    include Grape::DSL::Settings
    include Grape::DSL::InsideRoute

    attr_accessor :block, :source, :options
    attr_reader :env, :request, :headers, :params # <- метод request здесь присутствует
    ...

Но в случае с Method это не срабатывает. Если мы сами определили этот handler из Grape::Middleware::Error (на самом деле, из middleware-цепочки proxy-объекта Grape), то атрибуты Grape::Endpoint, такие как request, для него уже недоступны. В отличие от этого, Proc выполняется с self, равным endpoint, поэтому объект request там будет доступен. Это, кстати, можно проверить даже из хелпера в MealUp:

mealup/app/api/v1/helpers/response_helpers.rb:

def serialize_error(error)
  ...
  when SubscriptionRequiredError
    debugger # <- Ставим debugger перед тем местом, где должна произойти ошибка
    assign_rate_limit_headers(current_user, error.limit_key)
    error
  ...
end

Если :rescue_from определен с символом:

   70:         when SubscriptionRequiredError
   71:           debugger
=> 72:           assign_rate_limit_headers(current_user, error.limit_key)
   73:           error
   74:         else
   75:           error
   76:         end
(byebug) Grape::Middleware::Error === self
true
(byebug) Grape::Endpoint === self
false

Если :rescue_from определен с лямбдой или блоком:

   70:         when SubscriptionRequiredError
   71:           debugger
=> 72:           assign_rate_limit_headers(current_user, error.limit_key)
   73:           error
   74:         else
   75:           error
   76:         end
(byebug) Grape::Middleware::Error === self
false
(byebug) Grape::Endpoint === self
true

Проще говоря: Proc берёт self из места вызова, а Method — из своего receiver’а

Почему мы любим Ruby

Что ж, мы нашли способ пофиксить проблему. Тесты проходят, headers отбиваются на фронт и с успешным ответом, и с ошибкой. Наши пользователи смогут считать калории бесплатно, и знать, в какой момент им потребуется подписка. Но ТРИ строки, когда можно написать одну? Для любого Ruby разработчика это звучит как вызов. Поэтому, финальный фикс, который пошел в прод выглядит так:

mealup/app/api/v1/api.rb:

rescue_from SubscriptionRequiredError, with: ->(e) { render_error(e) }

Выводы

1. В Grape rescue_from с символом (with: :render_error) превращает обработчик в экземпляр Method, который жёстко привязан к объекту из middleware-цепочки и выполняется вне контекста Grape::Endpoint, из-за чего теряет доступ к request.

2. rescue_from с блоком или лямбдой сохраняет контекст Grape::Endpoint благодаря гибкости Proc.

3. Если ваш обработчик ошибки обращается к request, params, current_user или другим методам Grape::Endpoint — всегда используйте лямбду или блок.

4. Красивый синтаксис не всегда правильный. Иногда за красотой скрывается боль многочасового дебага. (Но Ruby - все равно классный).