⁣Неявное зависание Promise.all при отмене AsyncIterator через AbortController

Вы используете for await...of с асинхронным генератором и AbortController для отмены. Кажется, всё чисто, но Promise.all зависает намертво. Проблема в том, что вызов abort() вызывает return() генератора, но если внутри остался незавершённый промис (таймер, подписка, поток), он просто висит, и Promise.all никогда не завершится.

Как возникает утечка
Когда abort() срабатывает внутри for await...of, итератор завершается. Но если в генераторе есть запущенный, но не завершённый setInterval, await на потоке данных или подписка на событие, этот промис остаётся висеть в памяти. Например, генератор каждую секунду отправляет данные, а при abort обработчик завершает итерацию, но не очищает таймер. Promise.all ждёт этот таймер вечно.

Диагностика на практике
Добавьте в конец return() генератора console.log('return called'). Если return вызывается, а Promise.all не завершается — ищите, какой ресурс утекает. Используйте обёртку с таймаутом: Promise.race([Promise.all(...), AbortSignal.timeout(5000)]). В продакшне это спасёт от вечного ожидания, но не решит корень проблемы.

Совет по исправлению
Всегда оборачивайте тело асинхронного генератора в try/finally. В finally явно очищайте все ресурсы: удаляйте слушатели, отменяйте таймеры, разрешайте ожидающие промисы. Например, если внутри генератора есть setInterval:

async function* gen(signal) {
  const timer = setInterval(() => {}, 1000);
  try {
    while (!signal.aborted) {
      await new Promise(r => setTimeout(r, 100));
      yield data;
    }
  } finally {
    clearInterval(timer);
  }
}

Вывод: Каждый yield и await в асинхронном генераторе должен быть гарантированно завершён до конца итерации, иначе return() не прервёт внутренние промисы, что приведёт к невосстанавливаемому зависанию.

⁣Диагностика неявного deadlock в async_hooks при IPC в Node.js кластерах

Вы сталкивались с ситуацией, когда кластеризованное Node.js приложение потребляет 100% CPU без видимых ошибок, а event loop замирает? Часто причина — неявный deadlock в async_hooks, возникающий при смешивании синхронных IPC-вызовов через child_process.send и MessagePort.close в воркерах.

Гонка за ресурсами IPC
send() в child_process синхронно блокируется до отправки данных. Если следом вызвать port.close(), возникает замыкание: send() удерживает IPC-ресурс, close() ждет его освобождения, а async_hooks зависает в состоянии "ожидания завершения". Результат — ресурсы не освобождаются, ошибок нет, CPU занят вхолостую.

Production-пример: кластер с обработкой запросов, где каждый воркер отправляет результат через send и закрывает порт. После пары тысяч запросов — deadlock, все воркеры зависают.

Диагностика
Чтобы отловить проблему, включите логирование async_hooks с таймстампами:
- init для IPC-каналов появляется
- destroy приходит с задержкой или отсутствует вовсе
- No errors in logs

Практический совет: исправление
Замените синхронный send на асинхронный. Плохой паттерн:

send({ data }, (err) => { port.close(); });

Хороший паттерн:

await new Promise(resolve => process.send({ data }, resolve));
port.close();

Используйте MessageChannel вместо child_process.send — он избегает блокировки. Если deadlock уже произошел, убивайте воркер через worker.kill(), а не process.exit().

Профилактика
- Ставьте timeout на все IPC-операции
- Мониторьте async_hooks метрики через performance hooks
- Гоняйте кластер под нагрузкой с логированием ресурсов

Вывод: Синхронный IPC-вызов с последующим закрытием порта создает неявный deadlock в async_hooks, который проявляется только как 100% CPU и зависший event loop — переходите на асинхронные паттерны для всех межпроцессных коммуникаций.

⁣Зависание HTTP/2 прокси: как кастомные priority-фреймы убивают flow control

Когда параллельные стримы с разными приоритетами перестают отвечать, сессия жива, но данные не идут - проблема не в сети, а в управлении потоком. Разработчики часто путают висящие стримы с сетевыми таймаутами, теряя часы на отладку.

Две ловушки flow control
HTTP/2 имеет два окна управления потоком: на сессию (65535 байт по умолчанию) и на каждый стрим. При кастомных приоритетах (например, weight=256 у одного стрима и weight=1 у остальных) прокси начинает насыщать только приоритетный стрим. Остальные ждут, окно соединения исчерпывается - дедлок неизбежен.

Как диагностировать залипание
Чтобы поймать проблему:
- Смотри WINDOW_UPDATE фреймы. Если их число падает на уровне сессии, а на стримах нет - сигнал тревоги.
- Включи логирование priority. Когда более 80% веса приходится на один стрим, жди беды.
- Попробуй увеличить initial window size до мегабайта. Если зависание исчезает, копай в flow control.

Простой пример на Node.js
Вот как управлять окном приоритетов:

const http2 = require('http2');
const { HTTP2_HEADER_PATH, HTTP2_HEADER_METHOD } = http2.constants;

const client = http2.connect('https://example.com');
client.setLocalWindowSize(1048576);

async function sendRequest(path) {
  return new Promise((resolve, reject) => {
    const stream = client.request({
      [HTTP2_HEADER_PATH]: path,
      [HTTP2_HEADER_METHOD]: 'GET',
    });
    let data = '';
    stream.on('data', chunk => data += chunk);
    stream.on('end', () => resolve(data));
    stream.on('error', reject);
  });
}

Promise.all([
  sendRequest('/api/1'),
  sendRequest('/api/2'),
  sendRequest('/api/3')
]);

Типичная ошибка и её решение
При кастомных приоритетах убедись, что сумма весов не даёт перекоса под 80% на один стрим. Следи за stream.state: если localWindowSize почти ноль, а remoteWindowSize нет - это залипание. На прокси-сервере проверяй, не блокирует ли nghttp2 флаг NGHTTP2_FLAG_PRIORITY_OPEN.

Вывод: Контроль баланса весов приоритетов и мониторинг WINDOW_UPDATE фреймов на уровне сессии критичен для предотвращения дедлоков в параллельных стримах HTTP/2.