workerd отримав writable file streams і жорсткішу перевірку SQLite

У workerd v1.20260901.1 з’явилася TypeScript-реалізація FileSystemWritableFileStream, а test coverage для encoding і compression streams перенесено у повніші набори перевірок. Реліз також виявляє SQLite handles, які могли залишатися відкритими, якщо ініціалізація завершилася помилкою. Це невеликий за кількістю пунктів, але практичний набір змін для локального runtime serverless-застосунків.

Що дає FileSystemWritableFileStream

Writable file stream — це абстракція для послідовного запису, яка краще поєднується з Web Streams, ніж ручне накопичення всього payload у пам’яті. Типовий pipeline може читати потік, трансформувати chunks і передавати їх у destination з backpressure. Для великих файлів це важливо: застосунок не мусить одночасно тримати повну копію input і output.

Реліз повідомляє саме про реалізацію класу в TypeScript, а не про універсальну доступність будь-якого browser API у кожному середовищі. Розробникам потрібно перевірити compatibility flags, runtime version і конкретний storage binding. Не слід припускати, що код із довільним локальним filesystem path автоматично стане доступним у ізольованому worker.

Encoding і compression перевіряють як цілі pipeline

Окремі pull requests додають encoding streams suite та compression streams suite й переносять наявні тести TextEncoderStream, TextDecoderStream, CompressionStream і DecompressionStream. Цінність тут не в новій назві API, а у ширшій перевірці сумісності: chunk boundaries, завершення потоку, помилки й backpressure часто проявляють баги, яких немає при обробці одного короткого buffer.

Для прикладного коду це привід додати власні integration tests із Unicode на межах chunks, порожніми потоками, великими payload, пошкодженим compressed input і раннім cancel. Позитивний тест «hello world пройшов» не показує, що decoder коректно переживає розділений багатобайтовий символ або що compressor закриває фінальний блок.

SQLite handle не повинен переживати failed init

Ще одна зміна ловить leaked SQLite handles під час помилки ініціалізації. Такий витік небезпечний не лише пам’яттю. Відкритий database handle може утримувати file descriptor, lock або службовий стан, через що наступна спроба старту поводиться інакше за першу. У довгоживучому процесі повторні failed init накопичують ресурси й ускладнюють діагностику.

Release note не стверджує, що було втрачено дані або що витік доступний віддаленому атакувальнику. Коректне трактування — посилено lifecycle cleanup і додано виявлення ресурсу, який не закрився в error path. Після оновлення варто повторити тести пошкодженої схеми, помилкової міграції, відсутнього storage та примусового скасування startup.

Підтримка CFI-icall coverage

Build-система отримала підтримку coverage для indirect calls у межах Control Flow Integrity. Це інструментальна зміна для розробників runtime: вона допомагає бачити, які непрямі виклики покриваються тестами під CFI-інструментацією. Для кінцевого застосунку сам пункт не означає автоматичного ввімкнення нового security mode, але покращує здатність проєкту тестувати захисні build-конфігурації.

Практичний висновок: реліз цікавий командам, які працюють зі streaming I/O або локальним SQLite. Оновлюйте runtime через staging і тестуйте не лише успішний шлях, а й cancel, пошкоджені дані та повторний старт після помилки.

План перевірки

• Зафіксувати runtime version і compatibility date у test та production середовищах.
• Прогнати streaming-запис на великих файлах із контролем peak memory і backpressure.
• Перевірити UTF-8 символи, розділені між chunks, та пошкоджені compressed streams.
• Симулювати невдалу SQLite initialization і переконатися, що повторний старт не бачить зайвих locks.
• Звірити dependency update у складі релізу з власними native або compatibility constraints.

Обмеження

Це щоденний release workerd, а не велике product announcement. Нотатки не містять benchmark, security advisory чи гарантії доступності API у всіх хостингових продуктах. Публікація описує open-source runtime; конфігурацію конкретної платформи слід звіряти окремо. Новий stream API не скасовує ліміти на розмір, квоти storage та перевірку вхідних даних.

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

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