Асинхронність: Promises, async/await і паралельність

Що таке Promise і в яких станах він буває?

Promise (проміс) — це обгортка над результатом асинхронної операції, якого в момент створення ще немає. Живе він в одному з трьох станів: pending (операція триває), fulfilled (успіх, є значення) і rejected (провал, є причина, зазвичай Error). Найважливіше — перехід зі стану очікування трапляється лише раз і фіксується назавжди: такий Promise називають settled, і його результат уже не переграти. Саме ця незмінність прибирає стару біду колбеків, коли обробник могли смикнути двічі й розсинхронити стан. Для автотесту це означає передбачуваність: результат асинхронного кроку не «мерехтить», його безпечно читати.

Чому колбеки виявилися незручними й що штовхнуло до Promise?

Дві причини. Перша поверхнева — «піраміда судного дня»: кожна залежна операція додає рівень вкладеності, і код сунеться вправо, доки не стає нечитабельним. Друга глибша — інверсія контролю: ти віддаєш свою функцію чужому коду й мусиш вірити, що він смикне її рівно раз і правильно передасть помилку. Обробку помилок доводилося вручну дублювати на кожному рівні, а звичайний try/catch навколо не рятував — колбек стріляє пізніше, коли зовнішній блок уже відпрацював. Promise забрали контроль назад: об'єкт сам сигналить про завершення, а помилки збираються в одному місці.

Чим відрізняються .then, .catch і .finally?

.then реагує на успіх і повертає новий Promise — саме тому виклики зчіплюються в ланцюг, а не громадяться. .catch перехоплює відхилення з будь-якого кроку вище по ланцюгу, тож одного .catch наприкінці досить, щоб зловити помилку звідусіль. .finally спрацьовує в будь-якому фіналі — сюди кладуть прибирання на кшталт «сховати лоадер» чи «закрити з'єднання». Тонкий момент: помилка, кинута всередині колбека, не вилітає назовні звичайним винятком, а переводить наступний Promise у rejected — тому й ловиться через .catch, а не через try/catch навколо ланцюга.

Що повертає async-функція і що насправді робить await?

async-функція завжди повертає Promise — навіть якщо всередині ти повертаєш звичайне число, воно автоматично загорнеться у виконаний Promise. Тому результат такої функції теж треба await-ити, інакше отримаєш проміс замість значення. await же розпаковує Promise: чекає, доки той залагодиться, і віддає значення або кидає помилку, якщо стан став rejected. По суті це синтаксичний цукор над .then, який дозволяє писати асинхронний код у вигляді звичайних послідовних рядків. Під капотом — ті самі Promise, просто без ланцюгів.

await блокує потік виконання?

Ні, і це ключове непорозуміння. await призупиняє тільки поточну async-функцію, а не весь JS-рушій. Поки ця функція «спить», чекаючи на результат, event loop вільний крутити інший код — обробляти події, інші проміси, таймери. Тобто «зачекати» тут не дорівнює «заморозити все»: JS лишається однопотоковим і неблокувальним. Практичний наслідок для тестів: між двома сусідніми await можуть прослизнути інші мікрозадачі й оновлення стану, тож не варто уявляти, ніби рядки біжать строго впритул без жодної паузи.

Як обробляти помилки в async/await порівняно з колбеками?

У колбеках помилку доводилося перевіряти вручну першим аргументом (if (err)) на кожному рівні, а try/catch навколо не працював. З await усе повертається до звичного: якщо Promise відхилився, await кине справжній виняток, і його ловить нормальний try/catch. Це головна ергономічна перевага синтаксису — уся обробка помилок ланцюга збирається в один catch-блок, а finally гарантує прибирання незалежно від результату. У тесті це означає, що асинхронний збій не «губиться», а спливає туди, де його реально видно.

await у циклі проти Promise.all — коли що обирати?

await усередині циклу виконує операції строго по черзі: кожна чекає на попередню, і затримки складаються — десять запитів по 200 мс дадуть близько двох секунд. Якщо операції незалежні, це марна втрата часу: правильно запустити їх усі одразу й дочекатися разом через Promise.all, і тоді ті самі десять запитів укладуться приблизно в 200 мс. Послідовність лишають свідомо лише там, де крок справді спирається на результат попереднього (спершу створити користувача, потім його замовлення за отриманим id) або де важливий порядок побічних ефектів. Класичний приклад паралельності — насидати пачку тестових акаунтів одночасно замість очікування кожного окремо.

Чим Promise.all відрізняється від Promise.allSettled?

Promise.all працює за принципом fail-fast: щойно хоч один проміс відхилився, увесь all миттєво падає з цією ж причиною, а результати решти губляться (самі операції при цьому не скасовуються — просто їхні значення нікуди не потраплять). Promise.allSettled, навпаки, не відхиляється ніколи: він чекає, доки всі залагодяться, і повертає масив об'єктів-статусів — для кожного або значення, або причину відмови. Обирати all варто, коли потрібні геть усі результати за принципом «все або нічого». А allSettled — коли запускаєш пачку незалежних перевірок чи очищень і хочеш зібрати повну картину, а не впасти на першому збої.

У чому різниця між Promise.race і Promise.any?

Promise.race залагоджується найпершим результатом, що прийшов, — байдуже, успіх це чи помилка; переміг перший, хто фінішував. Promise.any розбірливіший: він чекає на перший успішний проміс і відхиляється, лише коли провалилися геть усі, повертаючи тоді AggregateError зі списком усіх помилок. Через це в них різні застосування: race класично роблять таймаутом — гонка корисної операції проти проміса, що відхилиться через N секунд; а any беруть, коли досить першого, що спрацював (наприклад, перша жива репліка з кількох). Плутати їх на співбесіді не варто — це типова перевірка на розуміння поведінки при частковому збої.

Чому forEach з async-колбеком не чекає на проміси?

Тому що Array.forEach взагалі не дивиться на значення, яке повертає колбек. Ти передаєш йому async-функцію, кожен виклик віддає Promise, але forEach їх ігнорує — усі колбеки стартують «у повітря», а код нижче біжить далі, не дочекавшись жодного. Виглядає як послідовна обробка з await, а насправді порядок і завершення ніхто не контролює. Лікується це for...of з await (коли треба по черзі) або await Promise.all(ids.map(...)) (коли можна паралельно). Та сама пастка чигає на map/filter з async-колбеком: вони повертають масив промісів, а не масив готових значень.

Що таке floating promise і чому через нього тест зеленіє завжди?

Floating promise — це асинхронний виклик без await: код не дочекався результату й полетів далі, лишивши проміс «плавати». У Playwright web-first assertion (наприклад, перевірка видимості) повертає Promise із вбудованими ретраями. Забудеш await перед нею — тест не стане чекати, ретраї не встигнуть відпрацювати, і перевірка «пройде» навіть тоді, коли кнопки на сторінці немає. Тобто тест стабільно зелений, але нічого не перевіряє — найнебезпечніший різновид фальшивого проходження. Ловить цей клас багів eslint-правило @typescript-eslint/no-floating-promises, і в тестовому проєкті його варто вмикати.

Що виведе код зі setTimeout(…, 0) і .then, і чому саме так?

Асинхронні задачі стоять у двох чергах: колбеки промісів (.then, продовження після await) — це мікрозадачі (microtasks), а setTimeout/setInterval/події вводу — задачі (tasks) з черги задач. Правило порядку жорстке: після кожної синхронної ділянки JS-рушій спорожняє всю чергу мікрозадач і лише потім бере з черги задач наступну. Тому .then завжди відпрацює раніше за setTimeout(fn, 0), навіть якщо таймер стоїть у коді вище. У класичному прикладі з рядками console.log('1'), setTimeout, Promise.resolve().then, console.log('4') вивід буде 1, 4, 3, 2: спершу синхронні 1 і 4, далі мікрозадача 3, і аж потім задача з черги задач 2.

Чому фіксований sleep в автотестах — антипатерн?

Бо ти вгадуєш час замість того, щоб чекати на подію. Жорстка пауза (waitForTimeout(3000), sleep) має два однаково погані результати: або марно гальмує зелений прогін на секунди, яких не знадобилося, або все одно падає під навантаженням, коли операція цього разу зайняла трохи довше. Спокуса «полагодити» плаваючий тест затримкою лікує симптом, а не причину — сам floating promise чи неправильну синхронізацію. Правильно — очікувати конкретну умову: елемент став видимим, відповідь прийшла, стан змінився. Саме на цьому побудовані auto-waiting і web-first assertions, які підбирають час самі.

Один проміс у Promise.all відхилився. Що стається з рештою?

Promise.all миттєво переходить у rejected з причиною цього першого збою — це і є fail-fast. Але важливий нюанс: решта промісів не скасовується. Вони фізично продовжують виконуватися (запити летять, дані пишуться), просто їхні результати вже нікуди не потраплять, бо загальний проміс уже впав. Тому не варто вважати, що all «зупинив» усе інше — він лише перестав чекати на нього. Якщо тобі потрібні всі результати незалежно від окремих збоїв (скажімо, прибрати десять сутностей і не впасти, якщо однієї вже немає), бери Promise.allSettled замість all.

Що таке unhandled rejection і як його не наплодити в тестах?

Unhandled rejection — це відхилений Promise, чиєї помилки ніхто не перехопив. Найчастіше він виникає, коли в ланцюгу забувають return або await перед вкладеним промісом: його відхилення не має куди «стекти» й лишається необробленим. У тесті це підступно, бо збій може не завалити крок явно, а спливти пізніше й у чужому місці — або взагалі лише як попередження в лозі. Дисципліна проста: кожен асинхронний виклик має бути або await-нутий, або свідомо повернутий далі по ланцюгу. Те саме правило, що ловить floating promise, страхує й від проковтнутих reject.

Як обмежити паралельність, щоб не завалити стенд чи не впертися в rate limit?

Promise.all спокушає запустити все одразу, але сто одночасних запитів проти спільного ресурсу легко впруться в обмеження частоти (rate limit) або перевантажать тестове середовище — і частина операцій почне падати «випадково». Тому за масової паралельності потрібен ліміт одночасних операцій — пул (concurrency pool): наприклад, обробляти дані порціями по N або тримати «семафор», що не пускає більше N промісів у роботу водночас. Готового вбудованого комбінатора для цього немає, тож обмежувач паралельності доводиться писати самотужки. Орієнтир: незалежні операції — паралельно, але з дахом, а не «усі разом любою ціною».

Три кейси, де асинхронність вирішує, зелений тест чи полювання за примарою: підготовка тестових даних послідовно проти паралельно (і чому teardown краще на allSettled), три різновиди забутого await у Playwright, що роблять тест фальшиво-зеленим, і таймаут через Promise.race замість жорсткого sleep. Скрізь — що саме дивитися і чому.

Кейс 1. Підготовка даних: await у циклі, Promise.all і allSettled

Тесту треба десять акаунтів перед стартом. Наївний варіант — цикл із await, і кожне створення чекає на попереднє, хоча вони одне від одного не залежать.

// Послідовно: 10 запитів по ~200 мс складаються в ~2 секунди
const users = [];
for (const seed of seeds) {
  users.push(await api.createUser(seed));   // кожен чекає на попередній
}

Операції незалежні, тож затримки складаються дарма. Запускаємо їх разом і чекаємо однією точкою:

// Паралельно: усі 10 стартують одночасно = ~200 мс
const users = await Promise.all(seeds.map((seed) => api.createUser(seed)));

Promise.all повертає масив результатів у тому самому порядку, що й вхідний масив, — тож users[0] відповідає seeds[0] незалежно від того, хто фізично відповів першим. Але для прибирання після тесту all — пастка:

test.afterEach(async () => {
  // ПОГАНО: якщо одного юзера вже немає, весь all падає fail-fast,
  // і решта може лишитися неприбраною
  await Promise.all(users.map((u) => api.deleteUser(u.id)));
});

Правильний teardown має пережити часткові збої — тут якраз allSettled:

test.afterEach(async () => {
  const results = await Promise.allSettled(users.map((u) => api.deleteUser(u.id)));
  const failed = results.filter((r) => r.status === 'rejected');
  if (failed.length) console.warn(`не прибрано: ${failed.length} з ${users.length}`);
});

Що дивитися і чому:

• Promise.all для незалежних операцій — головний виграш у швидкості. Але вмикати паралельність варто, лише коли крок справді не залежить від попереднього; інакше отримаєш гонку за результатом, якого ще немає.
• Fail-fast all небезпечний саме в очищенні. Одна сутність, якої вже немає, валить весь deleteUser-батч, і частина даних лишається на стенді — джерело 409 Conflict на наступному прогоні. allSettled доводить прибирання до кінця й дає повний звіт.
• Порядок результатів all збігається з порядком входу, а не з порядком завершення — на це можна покладатися при звірянні users[i] із seeds[i].
• Не насидайте сотні сутностей одним Promise.all. Проти спільного API це впреться в rate limit; тоді потрібен ліміт паралельності (порції по N), а не «усі разом».

Кейс 2. Три різновиди забутого await у Playwright

Найпідступніший баг автотесту — той, що робить його стабільно зеленим і водночас сліпим. Усі три приклади нижче «проходять» навіть тоді, коли застосунок зламаний.

// 1) Floating promise: web-first assertion без await
test('кнопка видима', async ({ page }) => {
  await page.goto('/dashboard');
  expect(page.getByRole('button', { name: 'Save' })).toBeVisible();  // ← немає await
  // тест зелений завжди: перевірка не дочекалась ретраїв, навіть якщо кнопки немає
});

// 2) forEach з async: колбеки стартують "у повітря"
test('видалити всіх', async ({ page }) => {
  const ids = ['a', 'b', 'c'];
  ids.forEach(async (id) => {
    await api.deleteUser(id);   // forEach НЕ чекає на ці проміси
  });
  await expect(page.getByTestId('list')).toBeEmpty();  // біжить ДО видалення
});

// 3) Проковтнутий reject: вкладений проміс без return/await
async function ensureUser(id: string) {
  api.createUser(id);   // ← без await: помилка створення нікуди не потрапить
}

Виправлення для кожного:

// 1) додати await — ретраї web-first assertion відпрацюють
await expect(page.getByRole('button', { name: 'Save' })).toBeVisible();

// 2) послідовно (for...of) або паралельно (Promise.all), але не forEach
for (const id of ids) await api.deleteUser(id);
// або: await Promise.all(ids.map((id) => api.deleteUser(id)));

// 3) await-нути вкладений виклик, щоб reject став винятком
async function ensureUser(id: string) {
  await api.createUser(id);
}

Що дивитися і чому:

• Забутий await перед expect — не сповільнення, а сліпота. Playwright-асерти повертають Promise із вбудованими ретраями; без await перевірка не встигає їх зробити й «зеленіє» на порожньому місці. Симптом — тест ніколи не червоніє, навіть коли фічу зламали.
• forEach ігнорує повернутий проміс за побудовою. Ті самі async-колбеки в for...of з await виконаються по черзі, а в Promise.all(map(...)) — паралельно; forEach не дає ні того, ні того.
• map/filter з async теж пастка — вони повертають масив промісів, а не значень; забудеш обгорнути в Promise.all, і далі по коду отримаєш [Promise, Promise, …].
• Увімкніть @typescript-eslint/no-floating-promises у тестовому проєкті — воно ловить усі три випадки статично, ще до прогону, і це найдешевший захист від фальшиво-зелених тестів.

Кейс 3. Таймаут через Promise.race замість sleep

Іноді треба обмежити асинхронну операцію часом — але не жорсткою паузою, а «або встигни за N секунд, або чесно впади». Це класичне застосування Promise.race: гонка корисної операції проти проміса, що відхиляється по таймауту.

function withTimeout<T>(promise: Promise<T>, ms: number, label = 'operation'): Promise<T> {
  const timeout = new Promise<never>((_, reject) =>
    setTimeout(() => reject(new Error(`${label} перевищила ${ms} мс`)), ms),
  );
  return Promise.race([promise, timeout]);   // хто перший залагодиться, той і виграв
}

// використання: очікуємо готовність бекенду, але не довше 5 секунд
await withTimeout(api.waitForHealthcheck(), 5000, 'healthcheck');

Порівняння двох підходів до «зачекати»:

Що дивитися і чому:

• Promise.race залагоджується першим-ліпшим — і успіхом, і помилкою. Тут це і потрібно: якщо promise встиг — беремо його значення; якщо раніше «вистрілив» таймер — отримуємо reject з осмисленим повідомленням, а не мовчазне зависання.
• Це не заміна auto-waiting. Для UI-перевірок Playwright уже ретраїть сам; withTimeout доречний для власних асинхронних операцій без вбудованого очікування (кастомний polling, зовнішній сервіс, черга).
• Таймер за собою не прибирається. Програний setTimeout лишається висіти до спрацювання; у довгих сесіях його варто чистити через clearTimeout у finally, інакше назбираються зайві задачі в черзі задач.
• sleep лишається антипатерном саме тому, що вгадує час; race не вгадує тривалість операції — він лише ставить стелю, за якою чесно фейлить.

Promise: стани і ланцюг

• Можу назвати три стани Promise (pending, fulfilled, rejected), пояснити, що перехід фіксується раз і назавжди (settled), і чому ця незмінність прибирає клас багів «колбек викликали двічі».
• Знаю різницю між .then (реагує на успіх, повертає новий проміс для ланцюга), .catch (ловить відхилення з будь-якого кроку вище) і .finally (спрацьовує завжди, для прибирання).
• Можу пояснити, чому помилку в ланцюгу ловить .catch, а не try/catch навколо нього.
• Розумію, що таке callback hell і чому головна біда колбеків — інверсія контролю, а не лише вкладеність.

async/await

• Знаю, що async-функція завжди повертає Promise, тож її результат теж треба await-ити.
• Можу пояснити, що await призупиняє тільки поточну функцію, а не потік — event loop лишається вільним.
• Розумію, що await розпаковує значення проміса або кидає виняток, якщо той rejected, тож помилки ловляться звичайним try/catch, на відміну від колбеків.
• Розумію, що async/await — синтаксичний цукор над тими самими Promise, а не окремий механізм.

Послідовно vs паралельно

• Знаю різницю між await у циклі (затримки складаються) і Promise.all (операції стартують разом).
• Можу пояснити, коли послідовність обов'язкова: крок залежить від результату попереднього або важливий порядок побічних ефектів.
• Розумію, чому масову паралельність треба обмежувати пулом, щоб не впертися в rate limit чи не перевантажити стенд.

Комбінатори Promise

• Можу пояснити, що Promise.all — fail-fast: падає на першому відхиленні, а результати решти губляться (хоча самі операції не скасовуються).
• Знаю, що Promise.allSettled не відхиляється ніколи й повертає статус кожного проміса — і коли він доречніший за all.
• Розумію різницю Promise.race (перший будь-який результат) vs Promise.any (перший успішний, падає лише коли всі провалились із AggregateError), і можу навести застосування: race для таймауту, any для «першої живої репліки», allSettled для пачки незалежних перевірок.

Мікрозадачі і задачі

• Знаю, що колбеки промісів (.then, продовження після await) — мікрозадачі, а setTimeout/події вводу — задачі з черги задач (task queue).
• Можу пояснити правило: вся черга мікрозадач спорожняється перед наступною задачею з черги задач, тож .then випереджає setTimeout(fn, 0).

Типові пастки в автотестах

• Розумію, що таке floating promise і чому забутий await перед web-first assertion робить тест фальшиво-зеленим; знаю, що eslint-правило @typescript-eslint/no-floating-promises ловить його статично.
• Можу пояснити, чому forEach з async-колбеком не чекає на проміси, і чим замінити (for...of з await або Promise.all(map)).
• Знаю, чому hard wait (sleep, waitForTimeout) — антипатерн, і чому правильно чекати на умову, а не на час.
• Розумію, як виникає unhandled rejection через забутий return/await і чому кожен асинхронний виклик має бути await-нутий або повернутий далі.