{
  "index": 81,
  "slug": "editorial-2025-10-practice-teaching-engineering",
  "title": "Promise.all не отменяет работу: как объяснить границу и проверить её",
  "excerpt": "Promise.all объединяет результаты асинхронных операций, но не управляет их остановкой. Разбираем модель, контрпример, проверку и отдельный контракт отмены.",
  "contentHtml": "<p>Симптом появляется после первой же ошибки: один запрос отклонился, обработчик получил исключение, а соседние запросы продолжают выполняться. В логах уже виден общий отказ, но база данных, сетевой клиент или внешний сервис ещё получают работу. Цена ошибки — лишний трафик, ненужные записи, гонки при очистке и неверное сообщение пользователю. Если эту границу объяснить неточно, команда начнёт искать отмену в месте, которое умеет только ждать.</p>\n<p>Тезис простой: <code>Promise.all</code> описывает исход группы promises, а не жизненный цикл операций, которые за ними стоят. Aggregate promise может отклониться на первой ошибке. Остальные входы при этом не получают приказ остановиться. Значит, ожидание и отмена — два разных контракта. Их нужно проектировать и проверять раздельно.</p>\n<h2>Модель: что именно объединяет Promise.all</h2>\n<p>Представьте два входа: <code>left</code> и <code>right</code>. Каждый из них обещает значение в будущем. Вызов <code>Promise.all([left, right])</code> создаёт третий promise. Он становится успешным, когда все входы успешны, и отклоняется, когда один вход отклоняется. При успехе значения идут в том же порядке, что и входы.</p>\n<p>Третий promise не владеет внутренней работой <code>left</code> и <code>right</code>. Он наблюдает их состояния и сообщает общий результат. Если <code>left</code> завершился ошибкой, aggregate promise может завершиться сразу. Уже начатый <code>right</code> не обязан завершаться в тот же момент. Если <code>right</code> сам изменяет состояние внешней системы, наблюдение за ним не откатывает это изменение.</p>\n<figure><img src='/assets/editorial/2025/teaching-engineering-2025-model-exercise-check.svg' alt='Схема: два входных promise сходятся в общий результат, а отмена остаётся отдельным контрактом' loading='lazy' /><figcaption>Общий promise сообщает результат группы. Отдельный сигнал отмены управляет конкретной операцией, если такой сигнал предусмотрен её API.</figcaption></figure>\n<h2>Минимальный пример с видимым порядком событий</h2>\n<p>Учебный пример ниже не обращается к сети, файлам или базе. Он вручную завершает второй promise после того, как общий promise уже отклонился. Так видна только семантика ожидания. Пример не доказывает, что какой-либо реальный клиент продолжит работу именно с такой задержкой.</p>\n<pre><code>let finishRight;\n\nconst right = new Promise((resolve) =&gt; {\n  finishRight = () =&gt; {\n    console.log('right finished');\n    resolve('cache value');\n  };\n});\n\nconst combined = Promise.all([\n  Promise.reject(new Error('left failed')),\n  right,\n]).catch(() =&gt; {\n  console.log('combined rejected');\n});\n\nawait combined;\nfinishRight();\nawait right;</code></pre>\n<p>Сначала появится <code>combined rejected</code>. Затем появится <code>right finished</code>. Это не означает, что aggregate promise «забыл» второй вход. Он уже сообщил общий отказ, но второй вход всё ещё может перейти в состояние fulfilled. Ожидание результата группы не стало командой отмены.</p>\n<p>Важна и другая деталь. <code>Promise.all</code> не создаёт сами операции. К моменту вызова promises часто уже запущены: функция вернула promise, сетевой запрос уже отправлен, чтение уже поставлено в очередь. Обёртка видит результат этой работы, но не получает универсального доступа к её внутренним ресурсам.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class='table-scroll'><table><caption>Диагностика ошибок вокруг Promise.all</caption><thead><tr><th scope='col'>Симптом</th><th scope='col'>Причина</th><th scope='col'>Проверка</th><th scope='col'>Действие</th></tr></thead><tbody><tr><td>После первой ошибки соседний запрос всё ещё виден в логах</td><td>Aggregate promise сообщает отказ, но не отменяет вход</td><td>Добавить отдельные метки старта и завершения каждой операции</td><td>Решить, нужна ли отмена, и передать сигнал в API операции</td></tr><tr><td>Код ловит общий отказ и считает работу законченной</td><td>Смешаны состояние aggregate promise и состояние ресурсов</td><td>Проверить, что происходит с каждым входом после <code>catch</code></td><td>Дождаться нужных cleanup-действий или описать их отдельный контракт</td></tr><tr><td>Пользователь нажал «отмена», но запрос продолжился</td><td>Кнопка меняет интерфейс, а сигнал не дошёл до транспорта</td><td>Проверить прохождение <code>AbortSignal</code> до вызова API</td><td>Связать действие пользователя с поддерживаемым механизмом отмены</td></tr><tr><td>После ошибки меняется общий объект</td><td>Одна из операций имеет побочный эффект</td><td>Сравнить состояние до запуска, после отказа и после завершения остальных входов</td><td>Сделать операцию идемпотентной, добавить компенсацию или изменить порядок</td></tr><tr><td>В сообщении указано «все запросы остановлены»</td><td>Вывод сделан по первой ошибке, а не по наблюдению ресурсов</td><td>Найти подтверждение остановки для каждого участника группы</td><td>Сузить формулировку до «общий результат отклонён»</td></tr></tbody></table></div>\n<h2>Как выглядит отдельная отмена</h2>\n<p>Отмена появляется только там, где её поддерживает исполнитель. Для браузерного <code>fetch</code> обычно передают <code>AbortSignal</code>, полученный от <code>AbortController</code>. Контроллер не превращает любой promise в отменяемый. Он передаёт сигнал в конкретный API, а API решает, как остановить или прервать свою работу.</p>\n<pre><code>const controller = new AbortController();\n\nconst requests = [\n  fetch('/api/profile', { signal: controller.signal }),\n  fetch('/api/limits', { signal: controller.signal }),\n];\n\ntry {\n  const responses = await Promise.all(requests);\n  // Обрабатываем ответы только после успеха всей группы.\n} catch (error) {\n  if (error.name === 'AbortError') {\n    // Это отдельный путь отмены, а не обычная ошибка данных.\n  }\n  throw error;\n}\n\n// Вызывается по явному решению приложения, например по кнопке.\ncontroller.abort();</code></pre>\n<p>В этом фрагменте есть важное ограничение: вызов <code>abort()</code> стоит после <code>try</code> только для наглядности механизма. В рабочем коде его вызывают из отдельного события или политики таймаута. Если один <code>fetch</code> уже успел изменить серверное состояние, прекращение ожидания ответа не отменит это изменение. Для серверной операции нужен серверный контракт: ключ идемпотентности, отмена задания, транзакция или компенсационное действие.</p>\n<p>Не следует использовать контроллер как универсальный откат. Он помогает остановить поддерживаемую передачу данных. Он не возвращает уже отправленный платёж, не удаляет запись и не отменяет произвольную функцию, которая просто вернула promise.</p>\n<h2>Положительный и отрицательный пути</h2>\n<p>Положительный путь начинается с успешных входов. Тогда aggregate promise возвращает массив значений в порядке входного массива. Это удобно, когда зависимый код может начать работу только после получения всех значений. Проверка должна подтвердить не только наличие двух ответов, но и соответствие позиции: первый результат относится к первому входу.</p>\n<p>Отрицательный путь начинается с отклонения одного входа. Aggregate promise сообщает ошибку, но у приложения остаются вопросы. Нужно ли дождаться остальных результатов? Нужно ли отменить их? Можно ли показать частичные данные? Нужна ли компенсация побочного эффекта? На эти вопросы <code>Promise.all</code> не отвечает. Если нужен итог каждого входа, включая ошибки, применяют <code>Promise.allSettled</code>. Если нужна остановка, добавляют API отмены. Если нужна повторная попытка, описывают её лимит и область действия отдельно.</p>\n<p>Отдельно проверяйте поздние события. Отмена может прийти после ответа сервера. Таймаут может сработать после записи на сервере. Первый отказ может появиться раньше, чем второй запрос заметит закрытый сигнал. Обработчик должен различать «мы перестали ждать», «транспорт получил отмену» и «внешняя операция действительно прекратилась». Это три разных наблюдения.</p>\n<h2>Порядок проверки</h2>\n<ol><li>Опишите каждую операцию отдельно: что она читает, что меняет и какой ресурс должен остановиться.</li><li>Зафиксируйте ожидаемый общий результат: все значения, первая ошибка или полный набор исходов.</li><li>Запустите два входа с разными задержками и запишите отдельные события старта, отказа, завершения и отмены.</li><li>Проверьте сценарий, в котором первый вход отклоняется, а второй завершается позже.</li><li>Если нужна отмена, передайте поддерживаемый сигнал в каждый исполнитель и проверьте его получение.</li><li>Проверьте поздний ответ после отмены: он не должен менять UI или состояние, если операция уже устарела.</li><li>Проверьте побочные эффекты отдельно: отмена ожидания не должна называться откатом без подтверждения внешней системы.</li></ol>\n<h2>Ограничения модели</h2>\n<p>Эта модель объясняет семантику группы promises, но не задаёт политику приложения. Она не решает, какой запрос важнее, как долго ждать, сколько раз повторять и как сообщать частичный результат. Для этих решений нужны отдельные правила и наблюдаемые сигналы.</p>\n<p>Она также не заменяет документацию конкретной библиотеки. Один клиент может поддерживать <code>AbortSignal</code>, другой — собственный метод отмены, третий — только закрытие соединения. Нельзя переносить поведение одного транспорта на другой по одному имени promise.</p>\n<p>Учебный код с ручным <code>finishRight</code> показывает порядок переходов в памяти. Он не является нагрузочным тестом, не измеряет задержки и не подтверждает поведение production-системы. В реальном сервисе проверяйте контракт библиотеки, логи транспорта и состояние внешнего ресурса.</p>\n<h2>Критерий готовности</h2>\n<p>Объяснение и код готовы, если читатель может ответить на четыре вопроса без догадки: какой promise сообщает общий результат, что происходит с остальными входами после первой ошибки, какой объект или API действительно принимает отмену и что происходит с уже выполненным побочным эффектом. В проверочном запуске должны быть видны отдельные события для aggregate promise и каждой операции. Для сценария отмены нужно подтвердить получение сигнала исполнителем, а для серверного изменения — отдельное подтверждение остановки или компенсации.</p>\n<p>Если на вопрос об остановке отвечают только названием <code>Promise.all</code>, объяснение не готово. Добавьте контрпример и укажите владельца отмены. Если такого владельца нет, честный результат звучит так: общий promise отклонился, а начатая работа может продолжиться.</p>\n<h2>Проверяемые источники</h2><ul><li><a href='https://ecma-international.org/wp-content/uploads/ECMA-262_16th_edition_june_2025.pdf' target='_blank' rel='noopener noreferrer'>ECMA-262, 16th edition, §27.2.4.1 Promise.all</a> — спецификация описывает общий promise, обработку входного iterable и отклонение через reject capability. Она не задаёт отмену внешней работы.</li><li><a href='https://raw.githubusercontent.com/mdn/content/3fad0447b4901e28fe88769976787d8d8b87d66d/files/en-us/web/javascript/reference/global_objects/promise/all/index.md' target='_blank' rel='noopener noreferrer'>MDN Web Docs: Promise.all(), commit 3fad0447</a> — справочное описание успешного результата, первой ошибки и отличия от <code>Promise.allSettled()</code>.</li></ul>"
}