Node.js 24.16.0 LTS: UUIDv7, req.signal і randomized tests без великого rewrite

Зачіпка

Node.js 24.16.0 вийшов 21 травня 2026 і вже позначений на сайті Node.js як latest LTS. Це не реліз для переписування сервісу, але в ньому є три маленькі речі, які можна швидко перевірити в реальному backend.

Мова про crypto.randomUUIDv7(), req.signal в HTTP request і randomization у вбудованому test runner. Разом це нормальний 30-40-хвилинний rollout: корисніші ID, менше зайвої роботи після client disconnect і більше шансів зловити flaky tests.

Проблема / Контекст

У release notes Node.js 24.16.0 ці зміни виглядають як кілька рядків серед десятків commit-ів. Але для команд на активній LTS-гілці це саме той тип оновлення, який можна перевірити рано: API вже в LTS, а blast radius маленький.

Три практичні сценарії:

• у логах, чергах і audit trail потрібні ID, які природно сортуються за часом;
• HTTP handler продовжує робити downstream work, хоча клієнт уже закрив вкладку або connection;
• тести проходять поодинці, але падають у CI через приховану залежність від порядку.

Це не означає “замінити всі UUID у проєкті сьогодні”. Кращий підхід - вибрати один вузький потік і перевірити, чи новий primitive реально прибирає біль.

Чому це важливо

Node LTS оновлення часто сприймають як maintenance chore: підняли version pin, прогнали CI, забули. Тут є сенс забрати практичну користь без великого проєкту.

UUIDv7 допомагає там, де ID часто дивляться люди або сортує база. UUIDv7 містить timestamp у старших бітах, тому записи легше групувати за часом без окремого трюку в назві або додаткового sort key.

req.signal допомагає не витрачати ресурси після client disconnect. А --test-randomize б’є по тестах, які залежать від глобального стану, shared fixture або порядку запуску.

Як це зробити

1. Підніми staging або CI до 24.16.0

Почни не з production. Онови Node у staging image, CI matrix або devcontainer і підтверди версію:

node --version
# v24.16.0

Після цього запусти звичайний build і тестовий набір. На цьому кроці мета проста: переконатися, що базова платформа не ламає поточний проєкт.

2. Візьми UUIDv7 тільки там, де потрібен timeline

У Node.js 24.16.0 crypto.randomUUIDv7() генерує UUID за RFC 9562. Документація Node.js зазначає, що такий UUID містить millisecond timestamp у старших 48 бітах і підходить як database key із time-based sorting. Межа теж важлива: clock не monotonic, тому не обіцяй строго зростаючий порядок для кожного ID.

Мінімальний приклад:

import { randomUUIDv7 } from 'node:crypto';

export function createAuditEvent(userId, action) {
  return {
    id: randomUUIDv7(),
    userId,
    action,
    createdAt: new Date().toISOString(),
  };
}

Доречні кандидати: audit events, request або trace IDs у логах, job IDs у черзі, append-only таблиці, demo/dev datasets. Погані перші кандидати: існуючі primary keys із foreign keys, public IDs, security-токени і місця, де порядок має бути строго послідовним.

disableEntropyCache краще не чіпати без конкретної security-вимоги. За замовчуванням runtime кешує випадкові дані для швидшої генерації.

3. Прокинь req.signal у downstream work

Новий signal на IncomingMessage абортується, коли socket закривається або request destroyed. Найпростіший виграш - передати його у fetch:

import http from 'node:http';

http.createServer(async (req, res) => {
  try {
    const upstream = await fetch('https://api.example.com/report', {
      signal: req.signal,
    });

    res.writeHead(200, { 'content-type': 'application/json' });
    res.end(await upstream.text());
  } catch (error) {
    if (error.name === 'AbortError') return;

    res.statusCode = 500;
    res.end('Internal Server Error');
  }
}).listen(3000);

AbortError після client disconnect не має перетворюватися на шумний production incident. Логуй його на debug-рівні або як нормальне cancellation.

Для DB calls все залежить від драйвера. Якщо бібліотека підтримує AbortSignal, передай req.signal. Якщо ні, не вигадуй власний cancellation layer без тестів.

4. Запусти randomized tests із seed

Node.js test runner у 24.16.0 отримав randomization. Базовий запуск:

node --test --test-randomize

Під час такого запуску runner друкує seed. Якщо впало, повтори той самий порядок:

node --test --test-random-seed=12345

Це практично для order-dependent багів. Замість “у CI іноді падає, локально ні” команда отримує відтворюваний сценарій.

5. Зроби rollout маленькими PR-ами

Нормальний порядок:

1. PR 1: оновити Node у CI або staging image до 24.16.0.
2. PR 2: додати один вузький randomUUIDv7() use case.
3. PR 3: прокинути req.signal в один handler із downstream fetch.
4. PR 4: додати окремий CI job або manual command для randomized tests.

Так легше побачити, яка зміна дала користь або проблему.

Що НЕ робити

Не замінюй усі UUID автоматично. Якщо ID уже живуть у database schema, URLs, integrations або exports, це migration, а не косметика.

Не обіцяй UUIDv7 як строгий sequence. Він добре сортується за часом, але це не заміна auto-increment, queue offset або transactional ordering.

Не ігноруй AbortError. Його треба обробляти явно, інакше нормальне cancellation перетвориться на зайві error logs.

Не вмикай randomized tests як блокер для всіх без першого baseline. Спершу проганяй окремо, збери seed-и й подивись, чи проблема справжня.

Не продавай LTS update як rewrite. Найкращі LTS-поліпшення часто заходять через маленькі, добре перевірені зміни.

Висновок

Node.js 24.16.0 LTS вартий уваги не через гучність релізу, а через дрібні API, які добре лягають у щоденну backend-роботу.

План дій:

1. Підніми staging або CI до v24.16.0.
2. Вибери один потік ID для randomUUIDv7().
3. Додай req.signal у handler, який робить downstream work.
4. Запусти node --test --test-randomize.
5. Зафіксуй seed для кожного падіння й розбирай flaky tests відтворювано.

Це не “великий Node upgrade project”. Це маленький LTS playbook, який варто перевірити на одному сервісі або одному CI job.

Джерела

• Node.js Blog: Node.js 24.16.0 (LTS) — https://nodejs.org/en/blog/release/v24.16.0/
• Node.js releases page — https://nodejs.org/en/about/releases/
• Node.js Crypto API: crypto.randomUUIDv7([options]) — https://nodejs.org/docs/latest-v24.x/api/crypto.html#cryptorandomuuidv7options
• Node.js HTTP API: message.signal — https://nodejs.org/docs/latest-v24.x/api/http.html#messagesignal
• Node.js Test Runner: randomizing tests execution order — https://nodejs.org/docs/latest-v24.x/api/test.html#randomizing-tests-execution-order