Celld riproduce bug di concorrenza con testing a simulazione deterministica

Un race sugli allarmi, legato al riuso di wake entry in object storage, emerge e si riproduce con il testing a simulazione deterministica usato dal team di celld¹.

Celld è un runtime per applicazioni Cloudflare Workers e Durable Objects da eseguire su propri server. Richiede solo uno store oggetti compatibile S3 come dipendenza esterna. Ogni cell esegue codice applicativo e ha un database SQLite. Gli autori ricordano i rischi delle ipotesi implicite nei sistemi distribuiti, come “La rete è affidabile” e “La latenza è zero”, dalle otto fallacie di Peter Deutsch. Un bug può dipendere dall’ordine preciso di messaggi, scritture e riavvii. Se l’ordine cambia al run successivo, riprodurre il problema diventa difficile¹.

Usano deterministic simulation testing. Il simulatore fa girare il codice di produzione di celld in un ambiente controllato. Separa la logica che sceglie la prossima azione dalla logica che la esegue. Così controlla l’ordine degli eventi e fa girare lo stesso codice di gestione eventi usato in produzione.

Il simulatore decide quando far partire task asincroni e come risponde lo storage. Può ritardare una scrittura o farla fallire. Può far avanzare il tempo simulato senza attendere il tempo reale. Testa il comportamento che dipende dal tempo, inclusi retry e allarmi.

Gli autori configurano quali richieste e quali guasti esplorare. Dentro questi limiti, il simulatore usa scelte casuali per generare richieste, selezionare la prossima azione, decidere l’esito delle operazioni di storage e scegliere quali fault introdurre e quando. La riproducibilità arriva da un seed che inizializza il generatore di numeri casuali: stesso codice, stesse impostazioni e stesso seed producono la stessa sequenza, gli stessi stati intermedi e lo stesso risultato. Cambiare seed esplora nuovi percorsi. Un seed che fallisce si può ripetere identico per isolare la causa e verificare la correzione¹.

Dopo ogni azione, un checker verifica invarianti definite dal test. Le invarianti sono condizioni che devono restare vere per tutta la run. Il test avvia celld nell’ambiente simulato, poi avanza per passi fino a un limite configurato. Se non ci sono più azioni disponibili, controlla le condizioni di completamento, per esempio se tutte le richieste previste sono terminate.

Una replay semplificata mostra un passaggio. Dopo che la Cell A ha inserito una riga in SQLite, i dati vengono salvati su object storage prima che celld riceva la conferma. In quel margine possono correre altre richieste o task. Gli interleaving inattesi fanno emergere bug. Il simulatore separa questi step e ne prova ordini diversi, poi ripete quello che espone l’errore¹.

Il race scoperto riguarda gli allarmi. Un allarme pianifica l’esecuzione di codice a un’ora specifica. L’orario è in SQLite. Per riattivare celle scaricate senza riaprire molti database, celld scandisce wake entry in object storage. Quando il bug è stato trovato, celld riutilizzava wake entry per ridurre le scritture. Un’app poteva cancellare un allarme alle 10:00 e impostarne uno alle 10:05. La voce delle 10:00 bastava a riattivare la cell in anticipo. Una volta attiva, celld leggeva 10:05 da SQLite e attendeva quell’ora. La cancellazione rimuoveva l’orario da SQLite e, una volta salvata su object storage, celld rispondeva successo al client. Un task di cleanup separato rimuoveva la wake entry delle 10:00 più tardi, quindi il client poteva impostare l’allarme delle 10:05 mentre il cleanup era ancora in attesa di partire. Dopo che celld conferma l’allarme delle 10:05, deve restare una wake entry che possa riattivare la cell entro le 10:05. L’invariante si viola quando il vecchio cleanup esegue dopo l’impostazione dell’allarme delle 10:05 e rimuove la wake entry ancora necessaria¹.

Il simulatore è in sviluppo e non è nel repository pubblico di celld, ma ha già trovato bug prima sconosciuti¹.