I Rust Workers ora possono riprendersi da un panic
Cloudflare ha introdotto il supporto per panic=unwind nei Rust Workers, permettendo il recupero automatico dagli errori senza perdere lo stato in memoria grazie al WebAssembly Exception Handling.
Il meccanismo si basa sul moderno WebAssembly Exception Handling, che permette di gestire gli errori senza perdere lo stato in
Fino a poco fa, un panic in un Worker Rust significava una cosa sola: la fine istantanea dell’istanza. Lo stato in memoria andava perso, le richieste successive trovavano un processo corrotto, e l’unica via d’uscita era ricaricare tutto da capo. Con l’annuncio ufficiale di Cloudflare di questo aprile 2026, quel scenario appartiene al passato: le Rust Workers supportano ora panic=unwind, abilitato dal moderno WebAssembly Exception Handling, e il recupero dagli errori diventa finalmente una funzionalità di prima classe.
La Fine del Panic Catastrofico
Il problema di fondo era strutturale. In workers-rs, i panic di Rust erano per definizione non recuperabili: un panic metteva il Worker in uno stato non valido, e le chiamate successive potevano produrre overflow di memoria o eccezioni a cascata. L’unica strategia disponibile era l’abort — buttare via l’istanza e sperare di ripartire puliti. Funziona, ma a un costo alto: tutto lo stato in memoria viene azzerato a ogni errore.
Con la versione 0.8.0 di Rust Workers, la storia cambia. Stando a quanto descritto nel blog di Cloudflare, è disponibile un nuovo flag --panic-unwind da aggiungere al comando di build. Secondo quanto riportato anche nell’annuncio tecnico di Cloudflare, ora quando si verifica un panic, le richieste in corso generano errori 500, ma il Worker si ripristina automaticamente e istantaneamente per le richieste future. Non è un compromesso: è un comportamento molto più vicino a quello che ci si aspetta da un sistema di produzione robusto.
Il Meccanismo Dietro le Quinte
Per capire come funziona, bisogna guardare sotto il cofano. Il WebAssembly tradizionale non ha un meccanismo nativo per lo stack unwinding — quell’operazione che, in un linguaggio come C++ o Rust, percorre la catena degli stack frame all’indietro, chiamando i distruttori e liberando le risorse prima di propagare un’eccezione. Senza questa capacità, un panic in Wasm era inevitabilmente catastrofico: nessun distruttore veniva eseguito, l’istanza restava in uno stato inconsistente, e l’unica opzione era distruggerla.
Il moderno WebAssembly Exception Handling cambia le regole. Si tratta di un’estensione dello standard Wasm che introduce istruzioni native per lanciare e catturare eccezioni all’interno del modulo, in modo che possano propagarsi correttamente attraverso i frame. Con questo supporto attivo, wasm-bindgen può intercettare i panic esportati dalle funzioni Rust, esporli a JavaScript come oggetti PanicError, gestire il reject delle promise negli export asincroni, e — dettaglio chiave — eseguire correttamente i distruttori Rust. L’istanza WebAssembly rimane valida e riutilizzabile. È come avere un sistema di checkpoint in un videogioco: l’eccezione si propaga in modo controllato, lo stato viene preservato fino all’errore, e il gioco riprende dal punto sicuro più recente invece di ricominciare dall’inizio.
Il supporto per il moderno WebAssembly Exception Handling ha richiesto un lavoro non banale lato runtime. Firefox lo supporta già da ottobre 2024 (versione 131), Safari dalla versione 18.4 di marzo 2025, Chrome dalla versione 138 di giugno 2025, mentre Node.js ha raggiunto il supporto completo con la versione 25.0.0 dell’ottobre 2025. Ma il team non si è fermato alla versione 25: ha contribuito attivamente a backportare il moderno exception handling anche alle release Node.js 24 e 22, garantendo così copertura sulle linee di rilascio ancora in uso. Sul fronte degli strumenti, wasm-bindgen introduce una funzione __wbg_reset_state() — descritta nella documentazione ufficiale di wasm-bindgen — che permette di re-inizializzare l’intero stato della libreria senza ricaricarla, utile per gli ambienti che riutilizzano lo stesso contesto JavaScript. Vale la pena notare che questa funzione è al momento supportata solo per i target module, web e nodejs.
Cosa Cambia per gli Sviluppatori
L’impatto più significativo si percepisce sulle applicazioni stateful. I Durable Objects di Cloudflare — oggetti con stato persistente in memoria che vivono su un singolo nodo dell’edge — erano i più penalizzati dal vecchio approccio abort: ogni panic azzerava lo stato in-memory accumulato, con conseguenze che potevano essere gravi in applicazioni che usano quell’oggetto come cache, coordinatore o lock distribuito. Con panic=unwind, lo stato sopravvive all’errore: il panic relativo a quella singola richiesta viene isolato e gestito, mentre l’istanza continua a servire le richieste successive con il proprio stato intatto.
Il contesto competitivo rende questo aggiornamento ancora più rilevante. Nel mercato dell’edge computing del 2026, dove Cloudflare Workers opera su oltre 330 punti di presenza globali, anche Fastly punta su WebAssembly per la sua piattaforma Compute — che compila il codice personalizzato in Wasm e lo esegue sull’edge tramite WebAssembly System Interface. In questo scenario, secondo il confronto tra piattaforme edge 2026, il supporto nativo a Rust e WebAssembly è già considerato un differenziatore competitivo. Portare il panic handling a un livello paragonabile a quello dei runtime nativi rafforza ulteriormente la posizione di Cloudflare per i carichi di lavoro più esigenti.
C’è anche un aspetto di governance dell’open source da tenere d’occhio. Già nel 2024, il Rust and WebAssembly Working Group è stato archiviato ufficialmente nel progetto Rust dopo circa cinque anni di inattività. Secondo il comunicato di sunsetting di Rust/WASM, il repository wasm-bindgen sarà trasferito a una nuova organizzazione dedicata, con nuovi maintainer. Questo passaggio di consegne, combinato con il lavoro sui backport di Node.js e con l’adozione da parte di Cloudflare, segnala che l’interesse attorno a wasm-bindgen è tutt’altro che in declino — anzi, si sta strutturando per un mantenimento più solido nel lungo periodo.
Quello che è appena arrivato in produzione non è una patch di emergenza: è la conseguenza logica di un percorso di maturazione che tocca lo standard Wasm, i runtime JavaScript, la toolchain Rust e le astrazioni di alto livello come workers-rs. Il risultato è un modello di esecuzione edge in cui Rust smette di essere un’opzione ad alto rischio per chi ha bisogno di affidabilità, e diventa una scelta concreta per costruire servizi che devono restare in piedi anche quando qualcosa va storto.
