Мастерство Async/Await: Продвинутая обработка ошибок и паттерны повторных попыток

Хотя синтаксис async/await делает асинхронный код читаемым, продакшн-приложения требуют сложной обработки ошибок, механизмов повторных попыток, тайм-аутов и стратегий резервного выполнения. Сетевые сбои, ограничения API и временные ошибки требуют устойчивого кода, который грамотно обрабатывает сбои. Давайте проанализируем комплексную реализацию async/await, которая решает реальные задачи.

Изначальная реализация содержала несколько критических проблем, которые могли вызвать сбои в продакшене. Рассмотрим исправленную версию и поймём, что было не так:

В исходном коде были несколько серьёзных ошибок. Во-первых, AbortController создавался внутри блока try, но должен быть доступен в catch для правильной очистки. Во-вторых, метод isRetryableError мог получать null/undefined параметры, вызывая ошибки выполнения — исправлено с помощью проверок на null. В-третьих, AbortError не отличался от других ошибок, что могло привести к бесконечным повторным попыткам при ручной отмене. В-четвёртых, объект error не использовал optional chaining при доступе к error.message в handleFailure, что могло вызвать сбой, если error был undefined.

Код использует Promise.race для элегантной реализации тайм-аута. Это заставляет фактический fetch соревноваться с promise тайм-аута. Кто завершится первым — тот выигрывает. Когда срабатывает тайм-аут, вызывается controller.abort() для отмены fetch-запроса, что предотвращает потерю пропускной способности и памяти. Этот паттерн лучше, чем просто обёртывать fetch в тайм-аут, так как он активно отменяет запрос, а не игнорирует его.

Метод calculateBackoff реализует экспоненциальный backoff — каждая повторная попытка ждёт всё дольше (1с, 2с, 4с, 8с). Это предотвращает перегрузку слабого сервера. Добавленный jitter (случайная задержка) предотвращает проблему «thundering herd», когда несколько клиентов одновременно делают повторные попытки, вызывая каскадные сбои. Эта комбинация является отраслевым стандартом для логики повторных попыток в распределённых системах и используется AWS, Google Cloud и крупными API.

Улучшенный метод isRetryableError теперь включает важные проверки безопасности. Сначала он проверяет, что хотя бы один параметр передан, предотвращая ошибки обращения к null. Явно проверяет AbortError и возвращает false — ручные отмены никогда не должны повторяться. Метод различает временные ошибки, заслуживающие повторной попытки (сбои сети, тайм-ауты, ошибки 5xx, лимиты 429) и постоянные ошибки (400, 404, 401). Это интеллектуальное принятие решений критично для продакшн-систем.

Исправленный код пытается разобрать тело ответа ошибки, предоставляя больше контекста при сбоях. Он прикрепляет объект response и разобранное тело к выбрасываемым ошибкам, позволяя вызывающему коду получить детальную информацию об ошибках. Использование optional chaining (?.) предотвращает сбои при доступе к потенциально undefined свойствам. Такой подход к защитному программированию обеспечивает стабильность клиента даже при неожиданных ответах API.

Вместо простого выбрасывания ошибок эта реализация возвращает структурированные объекты ответа с флагами успеха, данными, сообщениями об ошибках и метаданными, такими как количество попыток. Этот подход даёт вызывающему коду полную информацию для принятия решений — отображение удобных сообщений, логирование ошибок или запуск альтернативных процессов. Последовательный формат упрощает обработку ошибок в остальной части приложения.

Когда все повторные попытки неудачны, handleFailure реализует стратегию плавного деградационного поведения с корректной обработкой null. Optional chaining гарантирует, что код не падает, если error undefined. Если существуют данные для fallback (например, из предыдущего успешного запроса или значения по умолчанию), они возвращаются вместо полной ошибки. Это позволяет приложению оставаться функциональным даже при полной недоступности API. Флаг fromCache позволяет UI показать, что данные могут быть устаревшими.

Использование цикла for с операторами continue для логики повторных попыток чище, чем рекурсивные подходы или while. Оно явно указывает максимальное количество повторных попыток, предотвращает переполнение стека и ясно показывает поток выполнения. Счётчик попыток отслеживает прогресс и помогает при логировании. Выход из цикла при встрече с ошибками, не подлежащими повторной попытке, предотвращает ненужные задержки. Этот паттерн более читаемый и удобный для поддержки, чем альтернативы.

Исправленный код объявляет AbortController на уровне цикла, обеспечивая доступ в каждой итерации. Это позволяет правильно отменять запросы при тайм-ауте и ошибках. Создание нового AbortController для каждой попытки позволяет точно управлять отменой запроса. Современный fetch с AbortController — стандарт для отменяемых асинхронных операций в JavaScript, заменяя старые паттерны, такие как токены отмены promise.

Исправленная реализация добавляет методы PUT и DELETE вместе с GET и POST, обеспечивая полную поддержку операций CRUD. Каждый метод корректно настраивает тип запроса и, при необходимости, сериализует тело в JSON. Это делает клиента более универсальным для реальных взаимодействий с API, где часто используются все HTTP-методы.

Функция демонстрации теперь включает более информативный вывод в консоль с визуальными индикаторами (✓, ⚠, ℹ, ✗), которые упрощают чтение логов. Флаг fromCache корректно информирует пользователей, когда данные могут быть устаревшими. Обработка ошибок различает плавно деградированные ответы и неожиданные ошибки, предоставляя соответствующую обратную связь для каждого случая.

Продакшн-реализации должны добавлять паттерны circuit breaker для предотвращения каскадных сбоев, ограничение скорости для соблюдения квот API, дедупликацию запросов для предотвращения повторных вызовов и полноценную типизацию ошибок для разных режимов отказа. Интеграция с инструментами мониторинга помогает отслеживать частоту повторов, шаблоны ошибок и показатели производительности. Логика обновления токенов аутентификации часто относится к этому слою. Рассмотрите использование проверенных библиотек, таких как axios с перехватчиками или ky.

• Всегда проверяйте параметры в функциях проверки ошибок, чтобы предотвратить null reference errors.
• Используйте optional chaining (?.) при доступе к потенциально undefined свойствам, чтобы избежать сбоев.
• Объявляйте AbortController в соответствующей области видимости для корректного доступа при очистке.
• Отличайте AbortError от других ошибок — ручные отмены никогда не должны повторяться.
• Прикрепляйте детальный контекст ошибки (response, body) к выбрасываемым ошибкам для упрощения отладки.
• Promise.race элегантно реализует тайм-ауты, соревнуя fetch с promise тайм-аута.
• Экспоненциальный backoff с jitter предотвращает перегрузку серверов и проблему «thundering herd».
• Структурированные объекты ответа с флагами успеха дают последовательные и информативные результаты.
• Стратегии fallback позволяют плавно деградировать при полной недоступности API.
• Циклы for обеспечивают ясную, безопасную для стека логику повторных попыток, превосходящую рекурсию.
• Полное покрытие HTTP-методов (GET, POST, PUT, DELETE) делает клиента более универсальным.
• Защитное программирование с проверками на null и optional chaining предотвращает неожиданные сбои.