Восстановление и деградация: сброс состояния, ретраи с backoff, честные отказы

Восстановление — выселение состояния, а не ререндер

Когда boundary ловит ошибку, поддерево под ним размонтируется — но причина краша обычно живёт дальше: в состоянии родителя, в сторе, в URL-параметре. Краш — симптом; испорченное или неожиданное состояние — болезнь. Поэтому «retry» не может означать «отрисуй то же самое ещё раз» — то же состояние, тот же рендер, то же исключение, часто внутри одного кадра. Восстановление — это перемонтирование поддерева с выселением или заменой отравленного состояния.

react-error-boundary даёт оба направления этого хода:

<ErrorBoundary
  FallbackComponent={QuoteFallback}
  resetKeys={[symbol]}          // symbol меняется → boundary сбрасывается, поддерево перемонтируется
  onReset={() => refetchQuote()} // вместе с краш-состоянием убрать и причину
>
  <QuotePanel symbol={symbol} />
</ErrorBoundary>

resetKeys — декларативное направление: когда любое значение массива меняется — пользователь выбрал другой тикер, обновился параметр роута — boundary выходит из состояния ошибки и перемонтирует детей. Краш был про старый ввод, поэтому новый ввод — естественный триггер восстановления. resetErrorBoundary() (передаётся фолбэку) — императивное направление: кнопка Retry. Но её нажатие лишь снимает флаг ошибки самого boundary и перемонтирует детей со свежим локальным состоянием — если яд живёт вне поддерева, причину нужно убирать дополнительно в onReset: рефетч, чистка кэш-записи, сброс среза стора. Чистый React без библиотеки делает то же самое через key: поднимите key={attempt} на поддереве — React размонтирует старый экземпляр вместе со всем состоянием и смонтирует новый. Перемонтирование и есть суть: состояние испорченного ребёнка должно умереть, а идентичность по key — то, чем React решает, что умирает.

Ретрай с backoff — или станьте вторым отказом

Когда вы добавляете кнопку Retry, вы принимаете решение из распределённых систем от имени каждого клиента, который откроет эту страницу одновременно с остальными. Транзиентные сбои — 503, оборвавшееся соединение, брауноут — заслуживают ретрая. Но инцидент из Hook — стандартный режим отказа наивного ретрая: тысячи клиентов, ретраящих с одинаковым фиксированным интервалом, образуют синхронизированную волну (thundering retry), и добавленная вами нагрузка приходит ровно тогда, когда сервис меньше всего способен её переварить. Клиентский ретрай — это решение из распределённых систем, принятое в UI-коде. Дисциплина та же, что на бэкенде:

async function retryFetch(url, { tries = 3, base = 1000, cap = 30_000 } = {}) {
  for (let attempt = 0; ; attempt++) {
    try {
      const res = await fetch(url);
      if (res.status >= 500) throw new Error("HTTP " + res.status);
      return res;
    } catch (err) {
      if (attempt + 1 >= tries) throw err;             // бюджет исчерпан → boundary
      const delay = Math.min(cap, base * 2 ** attempt); // 1с, 2с, 4с … с потолком
      await new Promise((r) => setTimeout(r, delay + Math.random() * delay)); // джиттер
    }
  }
}

В этих десяти строках спрятаны три правила. Экспоненциальный backoff размазывает волну по времени — 1с, 2с, 4с вместо метронома. Джиттер рассинхронизирует клиентов — без случайного слагаемого тридцать тысяч дашбордов, упавших вместе, будут вечно ретраить вместе. Бюджет ретраев завершает историю: после бюджета бросаем в boundary и отдаём следующую попытку действию в человеческом темпе — кнопке Retry; кликающий пользователь естественно ограничен по частоте и естественно «джиттерится». И ретраить стоит только правдоподобно транзиентное: 503 — да, 400 от кривого запроса — нет; ретрай детерминированного сбоя — это цикл с лишними шагами.

Частичная деградация: error budget в применении к пикселям

Виджетный boundary делает больше, чем ловит, — он превращает краш в деградированный режим, пока остальная страница живёт. Это мышление error budget, применённое к UI: не у каждой области экрана одинаковые требования к доступности, значит, не каждая область должна падать с одинаковым радиусом поражения. Рельса рекомендаций может схлопнуться в пустой слот — и никто не потеряет денег. Виджет котировок может показать последний удачный тик с заметной пометкой «устарело» — это лучше и спиннера, и дыры. Вопрос уровня страницы: какие области декоративные, какие деградируемые со stale-данными, а какие критичны для целостности?

Сам фолбэк должен пользователю три правила честности. Сказать, что сломалось, на языке пользователя — «Котировки недоступны» лучше, чем «Что-то пошло не так», и оба лучше бесконечного спиннера, который врёт о прогрессе. Предложить настоящее следующее действие — Retry, проведённый через сброс с выселением причины, а не декоративный. И оставить выходы живыми — навигацию, остальную страницу, уже введённые данные. Фолбэк, запирающий пользователя, — второй отказ поверх первого.

И есть случай, когда частичная живучесть — неверная цель. Если сломалось критичное для целостности — auth-контекст, решающий, чьи данные рендерить; платёжный шаг, решающий, сколько списать; итог корзины, питающий заказ, — вежливая деградация вокруг рискует показать пользователю A сессию пользователя B или списать по устаревшей сумме. Здесь страницу роняют намеренно: полностраничный фолбэк, без бодрого «некоторые функции могут быть недоступны». Доступность — это фича; корректность — это продукт.