workerd оновив V8 до 15.3 і зробив трасування serverless-запитів точнішим

Відкритий serverless-runtime workerd отримав V8 15.3 і кілька змін, що роблять спостережуваність запитів точнішою. Stateless tasks тепер скасовуються до завершального демонтажу request context, завдяки чому їхні tracing spans закриваються коректно. Durable Objects публікують retry metrics лише тоді, коли повтор справді відбувся, та додають детальні причини результату.

Чому порядок завершення задач впливає на traces

У serverless-середовищі один HTTP-запит може запускати фонові або stateless tasks. Якщо контекст запиту знищується раніше, ніж задачі отримають сигнал скасування, telemetry span може залишитися незакритим або мати неправильну тривалість. У дашборді це виглядає як зависла операція, хоча код уже завершився.

Новий порядок спочатку скасовує задачі, даючи їм можливість коректно завершити spans, і лише потім руйнує request state. Для SRE це означає чистіші trace trees, менше хибних довгих запитів і точніші latency-метрики. Однак застосунок усе одно повинен явно обробляти cancellation і не розраховувати на нескінченний фоновий час.

Durable Objects: метрика лише для реального retry

Раніше показник повторів міг бути менш інформативним: сам факт проходження через певний код не завжди означав, що повтор справді відбувся. Тепер retry metric публікується лише за наявності retry, а outcomes розділено детальніше. Це полегшує пошук причин, коли проблеми створюють конфлікт стану, тимчасова недоступність або інший сценарій.

Важливо дивитися не лише на кількість повторів, а на їх співвідношення з успішними операціями та додану затримку. Короткий пік під час розгортання може бути нормальним; стабільне зростання зазвичай вказує на проблему конкуренції, перевантаження чи зовнішньої залежності.

Перехід на V8 15.3

Оновлення JavaScript engine приносить актуальні виправлення runtime та готує платформу до нових можливостей мови. Але сам номер V8 не гарантує, що кожна функція доступна у конкретному deployment: workerd може керувати flags і сумісністю окремо. Розробнику слід орієнтуватися на compatibility date та тести середовища, а не лише на таблицю підтримки V8.

Після зміни engine варто прогнати CPU-інтенсивні функції, роботу з streams, serialization і власні WebAssembly-модулі. Навіть сумісне оновлення може трохи змінити профіль пам’яті або оптимізацію гарячих функцій.

Streams, sockets і HTMLRewriter

До тестового набору додано sockets streams suite, а piping tests враховують спеціальні buffer writes. HTMLRewriter отримав більший fiber stack під AddressSanitizer. Це переважно внутрішні зміни якості, але вони знижують ризик регресій у потоковій передачі даних і допомагають знаходити помилки пам’яті під час санітарних збірок.

Додано також типи cf.originRangeRequests, що робить конфігурацію range requests до origin видимішою для TypeScript. Для медіа, великих файлів і часткового кешування правильна типізація зменшує кількість помилок у конфігурації.

Що перевірити оператору

• Порівняти trace completeness і кількість незакритих spans до та після оновлення.
• Створити окремі графіки для retry outcomes Durable Objects.
• Прогнати тести streams, sockets, HTMLRewriter і великих Range-запитів.
• Перевірити compatibility flags перед використанням можливостей V8 15.3.
• Виміряти latency й пам’ять на репрезентативному навантаженні.

Практичний висновок: реліз не додає одну гучну API-функцію, зате робить runtime передбачуванішим для експлуатації. Точні spans і retry metrics скорочують час між симптомом та реальною причиною збою.

Джерело та права

Матеріал є самостійним українським перекладом-переказом офіційних release notes workerd v1.20260909.1, опублікованих 9 вересня 2026 року. Репозиторій поширюється за Apache License 2.0. Перекладено й адаптовано редакцією «Бібліотеки програміста». Обкладинка створена редакцією за допомогою AI та не входить до першоджерела.