Что делать, если при запросе приходит 500?

Код 500 означает Internal Server Error. Сервер получил запрос, но не смог корректно обработать его из-за внутренней ошибки. Важно не застрять на фразе, что это ошибка бэкенда. На интервью покажите полный цикл действий: проверить запрос, защитить пользователя, собрать контекст и передать проблему туда, где ее можно исправить.

Коротко можно ответить так:

500 говорит о сбое на стороне сервера. Но я все равно проверю, не отправил ли фронтенд некорректный запрос. В UI обработаю ошибку, сохраню пользовательские данные и соберу request id, endpoint, время и шаги воспроизведения для команды бэкенда.

Начните с того, что находится под вашим контролем. Проверьте endpoint, HTTP-метод, заголовки, токен, формат тела и обязательные поля. Иногда сервер должен вернуть 400 или 422, но из-за слабой валидации падает с 500. Для пользователя это все равно выглядит как поломка. Для команды важно понять, какой запрос ее вызывает.

Пример безопасной обработки через fetch:

async function loadProfile() {
  const response = await fetch("/api/profile", {
    headers: { Accept: "application/json" },
  });

  if (!response.ok) {
    throw new Error(`Request failed with status ${response.status}`);
  }

  return response.json();
}

Важно: fetch не бросает исключение только из-за статуса 500. Если не проверить response.ok, код может попытаться парсить ошибочный HTML как JSON и сломаться уже на клиенте. В React-компоненте следите, чтобы устаревший ответ не перезаписал новое состояние. Для этого отменяйте запрос через AbortController или проверяйте актуальность запроса перед setState.

Пользователь не должен видеть stack trace, название внутреннего сервиса или SQL-ошибку. Ему нужно понять, что действие не завершилось, данные не потеряны и есть понятный следующий шаг. Для формы это особенно важно: не очищайте поля до подтвержденного успеха.

Плохой вариант:

// Плохо: форма очищается до того, как сервер подтвердил успех.
setForm(initialForm);
await submitForm(form);

Что сломается: при 500 пользователь потеряет введенный текст, а повторная отправка станет невозможной или приведет к ошибке с неполными данными. Если кнопка при этом не блокируется на время запроса, пользователь может отправить несколько одинаковых запросов.

Более безопасный вариант:

async function handleSubmit() {
  if (status === "loading") return;

  setStatus("loading");

  try {
    await submitForm(form);
    setStatus("success");
    setForm(initialForm);
  } catch (error) {
    setStatus("error");
  }
}

Так пользователь не теряет введенные данные при 500 и может повторить отправку. Кнопку отправки лучше отключить на время loading. Ошибку покажите в области с aria-live, чтобы ее услышали пользователи скринридеров. Если операция может создать дубликат, добавьте защиту на уровне API, например idempotency key, или сначала проверьте статус операции.

Retry полезен для временных сбоев, но опасен для действий с побочным эффектом. Если это загрузка списка, можно сделать 1-2 повтора с задержкой и затем показать кнопку "Повторить". Если пользователь ушел со страницы или сменил фильтр, старый retry нужно отменить, иначе он может перезаписать актуальные данные. Если это платеж, создание заказа или отправка формы, автоматический повтор без идемпотентности может создать дубль.

На интервью покажите, что вы не обрабатываете все 500 одинаково. Ошибка при загрузке второстепенного виджета не должна ломать всю страницу. Ошибка при сохранении формы должна сохранять введенные данные. Ошибка при оплате требует особенно аккуратного статуса, потому что пользователь может бояться повторного списания.

Команде, которая будет чинить сервер, нужен не общий текст про ошибку 500, а воспроизводимый контекст. Полезно передать:

• endpoint и HTTP-метод;
• точное время и окружение;
• status code и request id или trace id;
• версию фронтенда, браузер и роль пользователя, если это влияет на сценарий;
• шаги воспроизведения;
• обезличенный payload без токенов, паролей и приватных данных.

Так вы покажете, что умеете не только написать catch, но и довести проблему до исправления.

На интервью отвечайте в таком порядке: что означает 500, что вы проверяете на фронтенде, как защищаете пользователя, как собираете диагностику и как относитесь к повтору запроса. Это звучит сильнее, чем просто отправить всех смотреть логи сервера. Frontend developer отвечает за клиентское поведение и качество пользовательского сценария.

Короткая финальная формулировка:

500 я воспринимаю как серверную ошибку, но проверяю свой запрос и контракт API. В интерфейсе показываю понятное состояние, не теряю данные пользователя, ограничиваю retry и передаю команде сервера request id, endpoint, время и шаги воспроизведения.