workerd оновив WebSocket, TypeScript Streams і перевірки багатопотокових помилок

Відкритий runtime workerd отримав збірку v1.20260910.1 із серією внутрішніх змін у WebSocket, Streams, gRPC-конвертації, трасуванні SQLite-помилок і тестуванні конкурентного коду. Це не реліз із новим великим API для кінцевого користувача, але саме такі зміни визначають передбачуваність serverless-застосунків під навантаженням.

WebSocket: менше шуму від помилок користувацького коду

Оновлення змінює поведінку abort task у WebSocket: до внутрішнього журналу мають потрапляти лише помилки самого runtime. Це важливе розділення відповідальності. Якщо застосунок закриває з’єднання або обробник завершується очікуваною помилкою, платформа не повинна маскувати справжні runtime failures потоком однакових повідомлень.

Для операторів це потенційно означає чистіші error dashboards і точніші alerts. Але після оновлення варто перевірити, чи потрібні application-level помилки все ще фіксуються власною телеметрією. Внутрішнє логування runtime не замінює структуровані журнали застосунку, close codes і метрики тривалості WebSocket-сесій.

Уточнення й виправлення TypeScript Streams

До збірки ввійшов набір виправлень для TypeScript Streams і консолідація прогалин у тестах потоків. Release notes не обіцяють нової публічної семантики, тому розробникам не слід вигадувати залежність від внутрішньої реалізації. Практична дія — повторно прогнати сценарії з backpressure, cancellation, розгалуженням потоків та передаванням помилок між producer і consumer.

Потоковий код особливо чутливий до рідкісних комбінацій: consumer припиняє читання, поки producer ще планує chunks; abort signal приходить одночасно із завершенням; exception виникає після часткової відповіді. Розширення тестів зменшує ризик регресій, але не скасовує інтеграційні тести конкретного застосунку.

ThreadSanitizer охоплює більше тестів

Команда виправила сумісність Rust standard library із ThreadSanitizer та перевела всі тести під TSan. Sanitizer шукає data races — ситуації, коли різні потоки одночасно звертаються до спільної пам’яті без коректної синхронізації. Такі дефекти можуть роками не проявлятися локально й виникати лише під високим навантаженням або на іншій архітектурі.

Розширення TSan-покриття є сигналом зрілості інфраструктури тестування, а не доказом відсутності всіх race conditions. Sanitizer бачить лише виконані шляхи, тому якість залежить від набору тестів. Для власних native extensions або forks workerd доцільно запускати аналогічну конфігурацію на критичних сценаріях.

Cap’n Proto, SQLite та gRPC

Залежність capnp-cpp оновлено до свіжого стану з виправленнями навколо Executor::isCurrent і порядку setRunnable. Це внутрішня зміна планування; її значення проявляється у стабільності асинхронного виконання, а не у новому endpoint для розробника.

Маршрутизацію наявних SQLite Sentry-подій перенесено до exception details. Такий формат має допомогти групувати проблему разом із контекстом винятку замість розпорошення по окремих полях. Окремо з auto_grpc_convert знято experimental tag — ознака більшої зрілості функції, хоча сумісність конкретних схем і edge cases все одно треба перевіряти.

Runtime також відкриває compatibility-date.capnp і додає правила для нових API. Compatibility date залишається ключовим запобіжником: поведінка нового runtime не повинна мовчки змінювати старий deployment, доки команда свідомо не пересуне дату сумісності.

Безпечний порядок оновлення

• Зібрати staging на новій версії та не змінювати compatibility date одночасно.
• Прогнати WebSocket reconnect/abort, Streams backpressure і SQLite exception paths.
• Порівняти частоту internal errors та application errors у телеметрії.
• Для gRPC-конвертації перевірити реальні схеми, великі повідомлення й cancellation.
• Оновлювати production поступово, контролюючи latency, memory і crash rate.

Висновок: збірка від 10 вересня — технічне обслуговування фундаменту serverless-runtime. Вона найбільше цікава командам із WebSocket, потоковими відповідями, embedded SQLite або власними збірками workerd. Якщо ці шляхи не використовуються, оновлення все одно варто включити до планового циклу, але без заяв про неіснуючий приріст продуктивності.