SomeJob.perform_later
запускает асинхронное задание. Мы не можем знать, когда это закончится. Так что да, это сложно сообщить пользователю, что произошла ошибка. Но нужно ли информировать пользователя?
Хорошая вещь о заданиях в очереди - если они терпят неудачу, вы можете попробовать их снова. И опять. И снова, пока они не сработают или вы не сдадитесь. Когда вы работаете с API, в API и сети будут возникать временные ошибки, которые разрешаются сами собой. Не беспокойте пользователя этим.
ActiveJob имеет retry_on
, чтобы сообщить работе, какие исключения следует повторить.
class SomeJob < ApplicationJob
retry_on ActiveResource::ResourceNotFound
...
end
Теперь ваша работа будет спокойно повторяться в случае сбоя API.
ActiveResource::ResourceNotFound
- довольно грубое исключение, которое может произойти по многим причинам, поэтому в конечном итоге вы захотите перехватить и выбросить более конкретные исключения в вашей модели для более точной настройки обработки ошибок.
Число попыток ограничено. Если количество повторных попыток исчерпано, тогда человеку нужно вмешаться и посмотреть, что не так. Этот человек не пользователь, они не знают, как это исправить, это администратор.
Когда retry_on
исчерпывает свои попытки, исключительная ситуация всплывает в систему очередей, которая должна сообщить администратору, что в очереди есть мертвый элемент. Детали этого зависят от того, какую систему очередей вы используете.
Если пользователю нужно сообщить, есть несколько вариантов. Одним из них является добавление массива ошибок в модель User. Пользовательский интерфейс будет отображаться и отображать любые ошибки в массиве ошибок пользователя, возможно, в мгновение ока.
Затем вы передаете пользователя в работу. Если в задании есть какие-либо ошибки, они отлавливаются и добавляются в связанный с ним массив ошибок пользователя. В следующий раз, когда пользователь использует ваш пользовательский интерфейс, он увидит ошибки.