Что будет, если в Promise.all один Promise выдаст ошибку

Promise.all принимает набор значений или Promise и возвращает новый Promise. Он успешно завершается только тогда, когда успешно завершились все входные Promise. Если хотя бы один входной Promise стал rejected, общий Promise тоже становится rejected.

Главное слово для интервью: fail fast. Promise.all быстро сообщает об ошибке и не ждет, пока вы получите полный отчет по каждому элементу. Но это не значит, что он физически остановил остальные задачи.

В успешном сценарии массив значений идет в порядке входного массива. Скорость завершения отдельных Promise на порядок значений не влияет.

В этом примере ошибка приходит раньше, чем завершается медленный Promise. Общий catch сработает по первой ошибке.

const slowUser = new Promise((resolve) => {
  setTimeout(() => resolve("user"), 1000);
});

const fastError = new Promise((resolve, reject) => {
  setTimeout(() => reject(new Error("profile failed")), 100);
});

const settings = Promise.resolve("settings");

Promise.all([slowUser, fastError, settings])
  .then((values) => {
    console.log(values);
  })
  .catch((error) => {
    console.error(error.message); // "profile failed"
  });

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

Частая ошибка в интерфейсах: считать, что после первой ошибки остальные запросы уже не важны и точно остановлены. На самом деле запросы могут продолжать идти. Сервер может выполнить действие, а поздний ответ может попытаться обновить состояние.

Плохой пример: вы отправили несколько независимых изменений через Promise.all, одно упало, и вы показываете пользователю "ничего не сохранилось". Но часть запросов могла успешно изменить данные на сервере. Так появляется рассинхронизация UI и backend.

Безопаснее заранее решить, какой контракт нужен. Если операция атомарная с точки зрения пользователя, лучше иметь серверный endpoint, который применяет изменения транзакционно. Если операции независимые, показывайте результат по каждой операции через Promise.allSettled или свой формат результата.

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

const profilePromise = fetchProfile();

const recommendationsPromise = fetchRecommendations().catch((error) => {
  console.warn("Recommendations are unavailable", error);
  return [];
});

const [profile, recommendations] = await Promise.all([
  profilePromise,
  recommendationsPromise,
]);

Так делать можно, если fallback действительно безопасен. Не превращайте все ошибки в null без разбора. Иначе UI будет выглядеть успешным, хотя важная часть данных потеряна.

Promise.allSettled подходит, когда вам нужен полный отчет: что выполнилось, что упало и с какой причиной. Он не срывается на первой ошибке.

const results = await Promise.allSettled([
  fetchHeader(),
  fetchSidebar(),
  fetchFeed(),
]);

for (const result of results) {
  if (result.status === "fulfilled") {
    renderBlock(result.value);
  } else {
    renderBlockError(result.reason);
  }
}

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

Promise.all не отменяет операции. Если вам надо остановить сетевые запросы после ошибки или при уходе со страницы, используйте механизм конкретного API. Для fetch это обычно AbortController.

const controller = new AbortController();

try {
  await Promise.all([
    fetch("/api/user", { signal: controller.signal }),
    fetch("/api/settings", { signal: controller.signal }),
  ]);
} catch (error) {
  controller.abort();
  showError(error);
}

Такой код показывает идею, но отмена в catch не откатывает уже выполненные действия на сервере. Она только просит отменить операции, которые еще можно остановить. В реальном компоненте еще нужен cleanup при размонтировании. Иначе поздний ответ может прийти, когда экран уже закрыт. Пользователь увидит устаревшее состояние или лишнюю ошибку.

useEffect(() => {
  const controller = new AbortController();
  let active = true;

  async function loadJson(url) {
    const response = await fetch(url, { signal: controller.signal });

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

    return response.json();
  }

  async function load() {
    try {
      const [user, settings] = await Promise.all([
        loadJson("/api/user"),
        loadJson("/api/settings"),
      ]);

      if (!active) return;
      setData({ user, settings });
    } catch (error) {
      if (!active || error.name === "AbortError") return;
      setError(error);
    }
  }

  load();

  return () => {
    active = false;
    controller.abort();
  };
}, []);

Безопасная идея здесь не в самом Promise.all. Она в контракте вокруг него: при уходе со страницы запросы отменяются, а поздний результат не обновляет состояние.

Хороший короткий ответ на интервью может звучать так:

Если один Promise в Promise.all отклонится, весь Promise.all тоже отклонится с этой ошибкой. Это fail fast поведение. Остальные Promise не отменяются автоматически, они могут продолжить выполнение. Если мне нужны результаты всех операций, я выберу Promise.allSettled. Если ошибка отдельной операции ожидаемая и некритичная, обработаю ее внутри этого Promise и верну явный fallback.

Такой ответ показывает не только знание метода. Он показывает понимание риска для интерфейса: частичные side effects, потерянные результаты и неверное состояние загрузки.