Решили мы как-то добавить 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_errorrescue_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'}" endendclass 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'}" endend
И создадим их экземпляры:
middleware = Middleware.newendpoint = 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: Middlewarerequest: 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: Endpointrequest: "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 === selftrue(byebug) Grape::Endpoint === selffalse
Если :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 === selffalse(byebug) Grape::Endpoint === selftrue
Проще говоря: 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 — все равно классный).
ссылка на оригинал статьи https://habr.com/ru/articles/1030354/