{
  "index": 79,
  "slug": "editorial-2025-10-field-teaching-engineering",
  "title": "Promise.all не отменяет работу: как объяснить границу на рабочем примере",
  "excerpt": "После первой ошибки Promise.all возвращает rejected promise, но уже начатая работа входов не исчезает сама. Разбираем модель, контрпример и проверку, которые не дают перенести рецепт за пределы его условий.",
  "contentHtml": "<p>Симптом появляется в момент первой ошибки. Код ждёт несколько операций через <code>await Promise.all(tasks)</code>, одна операция отклоняется, обработчик сразу переходит в <code>catch</code>, а автор считает остальные операции остановленными. Позже выясняется, что один запрос всё ещё пишет данные, таймер всё ещё выполняется, а зависимая логика уже очистила состояние. Цена ошибки — повторные записи, лишние запросы и расследование, в котором приходится восстанавливать границу ответственности по логам.</p>\n<p>Тезис простой: <code>Promise.all</code> объединяет наблюдаемые исходы promises, но не является протоколом отмены работы. Он сообщает результат aggregate promise. Он не получает автоматически право остановить операцию, которая создала входной promise. Чтобы объяснить такой код без ложной гарантии, нужно разделить три объекта: входной promise, aggregate promise и внешнюю работу.</p>\n<h2>Сначала назовите задачу</h2>\n<p>Рецепт становится опасным, когда его показывают раньше задачи. Возьмём учебный сценарий: нужно получить профиль и настройки, а затем построить экран. Если любой результат недоступен, экран строить нельзя. Здесь <code>Promise.all</code> подходит как условие для зависимого шага: зависимый код запускается только после успешного исхода двух входов.</p>\n<p>Но это условие не отвечает на другой вопрос: что делать с операцией, которая уже началась и ещё не завершилась? Объединение результатов и остановка работы относятся к разным контрактам. Первый задаёт JavaScript. Второй должен задавать приложение, библиотека или владелец ресурса.</p>\n<figure><img src=\"/assets/editorial/2025/teaching-engineering-2025-feedback-loop.svg\" alt=\"Цикл проверки объяснения Promise.all: задача, модель aggregate, контрпример с оставшимся входом, проверка границы и следующий шаг\" loading=\"lazy\" /><figcaption>Правильное объяснение ведёт от задачи к модели, затем показывает оставшийся вход после reject и только после этого говорит о следующем действии. Схема учебная: она не показывает реальный сетевой trace и не доказывает поведение конкретного сервиса.</figcaption></figure>\n<h2>Механизм: два исхода вместо одного</h2>\n<p>Пусть в <code>Promise.all</code> переданы <code>profilePromise</code> и <code>settingsPromise</code>. JavaScript создаёт новый aggregate promise. Он выполнится успешно, если все входы выполнятся. Значения попадут в массив в порядке входного iterable, а не в порядке завершения. Если один вход отклонится, aggregate promise отклонится с первой причиной отказа.</p>\n<p>Это не означает, что второй вход получил команду отмены. Второй promise может уже завершиться, продолжить ожидание или скрывать за собой работу, которую можно прервать только отдельным API. Вызов <code>catch</code> наблюдает отказ aggregate. Сам по себе он не меняет жизненный цикл запроса, чтения файла, вычисления или записи.</p>\n<p>Отсюда следует отрицательный путь. Если профиль отклонился, нельзя выводить «настройки отменены». Можно вывести только «общий результат недоступен с такой причиной». Дальше код обязан использовать собственный контракт: сигнал отмены, закрытие ресурса, остановку очереди, компенсацию или безопасное ожидание остатка. Если такого контракта нет, честный ответ — отмена не определена.</p>\n<h2>Минимальный контрпример</h2>\n<p>Ниже намеренно узкий пример. Он не обращается к сети, диску, часам или данным пользователей. Один вход отклоняется сразу. Второй вход удерживается до явного вызова <code>finishRemaining</code>. Это позволяет увидеть порядок событий и не приписывать JavaScript поведение, которого в коде нет.</p>\n<pre><code>let finishRemaining;\nconst remaining = new Promise((resolve) =&gt; {\n  finishRemaining = () =&gt; resolve('settings');\n});\n\nconst combined = Promise.all([\n  Promise.reject(new Error('profile failed')),\n  remaining,\n]).catch(() =&gt; 'aggregate handled');\n\nawait combined;\nconsole.log('aggregate rejected');\nfinishRemaining();\nconsole.log(await remaining);\n// aggregate rejected\n// settings</code></pre>\n<p>После первой строки вывода aggregate уже обработал отказ. Но второй promise ещё существует. Функция <code>finishRemaining</code> завершает его позже. Пример доказывает только это: rejected aggregate не равен отмене каждого входа. Он не доказывает, как поведёт себя HTTP-клиент, база данных или очередь сообщений. Для каждого такого ресурса нужна отдельная документация и отдельный тест.</p>\n<p>Контрпример полезнее общей фразы «promises выполняются параллельно». Это слово слишком широкое. В JavaScript promise представляет состояние будущего результата; он не является универсальным дескриптором процесса, который можно остановить одним методом. Операции могут стартовать до создания aggregate, а их остановка может быть невозможна или требовать согласия внешнего владельца.</p>\n<h2>Три уровня, которые нельзя смешивать</h2>\n<table><caption>Симптом → причина → проверка → действие</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td><code>catch</code> сработал, но запрос продолжился</td><td>Aggregate наблюдает отказ, а клиент запроса не получил сигнал отмены</td><td>Посмотреть API запроса и его обработчик сигнала</td><td>Добавить явный cancel-контракт или признать работу неотменяемой</td></tr><tr><td>Результаты приходят в неожиданном порядке</td><td>Порядок завершения перепутан с порядком iterable</td><td>Сравнить индексы входов и trace завершения</td><td>Читать массив по исходным индексам, а не по времени</td></tr><tr><td>После одной ошибки обработчик пишет частичный результат</td><td>Зависимый шаг запускается не только после fulfilled aggregate</td><td>Проверить место вызова и ветки после <code>catch</code></td><td>Разделить partial result и готовый aggregate</td></tr><tr><td>Заменили <code>all</code> на <code>allSettled</code>, но проблема осталась</td><td>Нужен был протокол остановки, а изменили только форму отчёта</td><td>Назвать требование: все исходы или остановка работы</td><td>Выбрать combinator для отчёта и отдельно спроектировать отмену</td></tr><tr><td>Текст обещает «остановить всё»</td><td>Рецепт подменил причинную модель</td><td>Попросить показать объект, который посылает cancel</td><td>Сузить утверждение до aggregate и добавить отрицательный путь</td></tr></tbody></table>\n<h2>Как объяснить код без лишней теории</h2>\n<p>Начните с одной проверяемой фразы: «Экран строится только после двух успешных результатов». Затем назовите aggregate promise и покажите, где читается его результат. После этого добавьте отказ одного входа. Читатель должен увидеть, что зависимый шаг не запускается. Только теперь задайте вопрос о втором входе.</p>\n<p>Ответ должен быть конкретным. Если второй вход уже создан, у него есть собственное состояние. <code>Promise.all</code> не предоставляет в этом вызове метода <code>cancel</code>. Если вход связан с <code>fetch</code>, автор может передать <code>AbortSignal</code> и вызвать <code>AbortController.abort()</code>. Но это уже договор Fetch и конкретного кода приложения, а не свойство <code>Promise.all</code>. Даже сигнал не превращает любую серверную операцию в гарантированно отменённую: сервер мог принять запрос, а клиент мог лишь прекратить ожидание ответа.</p>\n<p>Такой ответ не должен звучать как универсальный рецепт отмены. Для учебного фрагмента достаточно показать место ответственности. В production нужно проверить, что делает клиент после abort, что происходит на сервере, как закрывается ресурс и допустима ли повторная попытка. Если эти условия не описаны, статья должна остановиться на границе знания.</p>\n<h2>Когда нужен другой combinator</h2>\n<p><code>Promise.all</code> выбирают, когда нужен общий успех всех входов и ранний отказ aggregate при первой ошибке. <code>Promise.allSettled</code> выбирают, когда нужно дождаться и сохранить статус каждого входа. Это разные требования. Переключение на <code>allSettled</code> не отменяет операции и не исправляет частичную запись.</p>\n<p>Например, экран может показывать независимые виджеты. Тогда полезно получить массив состояний и отрисовать ошибку только у одного виджета. Но платёжный сценарий, в котором нельзя продолжать без обязательного ответа, требует другой проверки: dependent action не должна начаться после rejected aggregate. Если же один вызов уже создал побочный эффект, combinator не решает вопрос компенсации. Его должен решить доменный контракт.</p>\n<p>Не стоит заменять <code>Promise.all</code> на последовательный <code>await</code> только ради иллюзии контроля. Последовательный запуск уменьшает число одновременно начатых операций, но не отменяет первую операцию при ошибке второй. Он также меняет задержку и нагрузку. Сначала зафиксируйте требование, затем выбирайте форму ожидания.</p>\n<h2>Проверяемый порядок действий</h2>\n<ol><li>Запишите исходную задачу одним предложением: какие результаты нужны и какой шаг зависит от них.</li><li>Назовите каждый входной promise и работу, которая стоит за ним. Не называйте promise самой работой.</li><li>Покажите fulfilled-путь: все входы завершились, aggregate вернул значения в порядке iterable, зависимый шаг получил полный набор.</li><li>Покажите отрицательный путь: один вход отклонился, aggregate отклонился, зависимый шаг не стартовал.</li><li>Проверьте оставшийся вход отдельным наблюдением. Ответьте, может ли он завершиться после reject и кто имеет право его остановить.</li><li>Если нужна отмена, найдите реальный контракт ресурса: сигнал, close, cancel, rollback или другой механизм подтверждения.</li><li>Проверьте частичные результаты и побочные эффекты. Отдельно решите, допустимы ли повтор, компенсация и повторный запуск.</li><li>Сформулируйте готовность одной проверяемой фразой и приложите тест для положительной и отрицательной ветки.</li></ol>\n<h2>Ограничения учебного примера</h2>\n<p>Пример выше фиксирует порядок наблюдений в памяти. Он не моделирует latency, сетевые разрывы, retry, таймауты, серверную обработку, блокировки базы, очередь или пользовательскую сессию. Нельзя переносить его вывод как готовую архитектуру. Его задача уже: показать, почему aggregate rejection не доказывает отмену входа.</p>\n<p>Есть и другой отрицательный путь: остановка может быть технически доступна, но логически запрещена. Например, сервер уже принял команду, и отмена клиентского ожидания не должна приводить к повторной команде без idempotency key. В таком случае «прервать ожидание» и «отменить побочный эффект» — два разных решения. Текст, который объединяет их одним словом «cancel», скрывает риск.</p>\n<p>Не заявляйте результат обучения или production-эффект по одному примеру. Можно проверить, что читатель назвал aggregate, вход и отдельный cancel-контракт. Нельзя из этого вывести, что он безопасно спроектирует любой асинхронный pipeline. Для такого вывода нужна другая проверка, привязанная к конкретной системе.</p>\n<h2>Критерий готовности</h2>\n<p>Объяснение готово, если независимый читатель может без подсказки ответить на четыре вопроса: какой результат объединяет <code>Promise.all</code>; что происходит при первом reject; может ли оставшийся вход закончиться позже; кто именно останавливает внешнюю работу. Код должен проходить тесты для fulfilled-пути и для отказа, а текст — не обещать отмену там, где в API нет такого контракта.</p>\n<p>Практическая финальная проверка короткая. Уберите названия методов и попросите восстановить модель по событиям. Затем верните код и сравните каждое утверждение с наблюдаемым результатом. Если для фразы «всё остановилось» нельзя назвать объект, который отправил сигнал остановки, замените её на точное утверждение об aggregate. Такая редактура сохраняет полезный рецепт и не переносит его за пределы условий задачи.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://tc39.es/ecma262/\" target=\"_blank\" rel=\"noopener noreferrer\">ECMAScript Language Specification: Promise.all</a> — актуальная спецификация ECMAScript и алгоритм combinator. Источник описывает aggregate-результат, но не задаёт отмену внешней работы.</li><li><a href=\"https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all\" target=\"_blank\" rel=\"noopener noreferrer\">MDN: Promise.all()</a> — официальная справочная документация с условиями fulfilled/rejected, порядком результатов и сравнением с <code>Promise.allSettled()</code>. Она не обещает автоматическую отмену входов.</li></ul>"
}