workerd переробив повторні спроби Durable Objects і виправив Python waitUntil

Відкритий runtime workerd отримав збірку v1.20260911.1 із точковими змінами у Durable Objects, Python workers, Streams і Node-сумісності. Найпомітніша архітектурна робота — refactor механізму повторних спроб Durable Objects, який тепер не прив’язаний лише до fetch-сценарію.

Retries стають незалежними від fetch

Durable Objects використовують послідовний стан для координації запитів на edge. Логіка retry, жорстко вбудована у fetch-шлях, ускладнює повторне використання для інших операцій і тестування станів помилки. У новій збірці цей механізм реорганізовано так, щоб він був fetch-agnostic.

Release notes не обіцяють нового публічного API або змін конкретної кількості спроб. Тому правильний висновок — внутрішня модель стала універсальнішою, а не те, що всі Durable Objects автоматично отримали іншу політику надійності. Командам із власними збірками workerd варто тестувати idempotency, backoff і повторне виконання операцій зі станом.

waitUntil у Python workers

Патч тепер охоплює не лише ctx.waitUntil, а й workers.wait_until. Обидва шляхи використовуються для фонової роботи, яка має продовжитися після формування основної відповіді. Розбіжність між ними могла створювати ситуацію, коли одна форма виклику отримувала виправлену семантику, а інша залишалася на старому шляху.

Після оновлення потрібно перевірити реальні задачі: доставку telemetry, запис до сховища, очищення ресурсів і поведінку exception. waitUntil не перетворює edge worker на необмежений queue processor; часові та ресурсні ліміти середовища залишаються чинними.

Зрозуміліша помилка випадковості на верхньому рівні

Python workers отримали точніше повідомлення, коли випадковість використовується на top level. Для ізольованих або відтворюваних execution contexts генерація випадкового значення під час ініціалізації модуля може бути проблемною: значення здатне пережити більше одного запиту або порушити очікування runtime щодо детермінованості.

Краще повідомлення скорочує час діагностики, але не змінює саму архітектурну рекомендацію: request-specific randomness слід створювати у відповідному request context. Секрети, токени та криптографічні nonce мають використовувати дозволений генератор і не повинні кешуватися на рівні модуля без чіткої причини.

Streams і порядок зміни стану

У identity transform stream виправлено порядок resolve та state change. Потоковий код чутливий до таких дрібниць: promise може повідомити про завершення раніше, ніж внутрішній стан фактично став доступним наступному обробнику. Наслідками бувають рідкісні зависання, подвійне завершення або помилки, що проявляються лише під навантаженням.

Це внутрішнє виправлення, тому автори не наводять гарантованого приросту продуктивності. Для користувача практична дія — прогнати integration tests із piping, cancellation, backpressure і швидким закриттям producer та consumer.

Node-сумісність: BoundSocket

Модуль node:net отримав net.BoundSocket. Новий тип стосується socket, уже прив’язаного до локальної адреси або порту, і розширює поверхню сумісності з Node API. Перед використанням потрібно звірити поведінку саме workerd із Node: наявність символу ще не гарантує підтримку кожного низькорівневого параметра чи сценарію ОС.

• Оновлювати runtime спочатку на canary deployment.
• Перевірити Durable Object operations на повторне виконання та idempotency.
• Протестувати обидва Python API для фонового виконання.
• Додати stress-тести для Streams і контроль незавершених promise.
• Власні Node-сумісні бібліотеки перевірити окремо з BoundSocket.

Висновок: збірка від 11 вересня — технічне обслуговування фундаменту edge runtime. Вона найбільше важить для платформних команд, які використовують Durable Objects або Python workers і потребують передбачуваних retries та коректного завершення фонових і потокових операцій.