Un'operazione infrastrutturale può durare più di una richiesta web e può coinvolgere passaggi successivi. Per questo Fliclic distingue almeno la richiesta, l'esecuzione, il successo e l'errore.
Alcuni workflow attraversano checkpoint funzionali. La creazione di un ambiente, per esempio, può consegnare il lavoro al flusso WordPress o alla duplicazione prima di raggiungere lo stato finale. “Processo terminato” non significa sempre “ambiente pronto”: può significare che una fase ha preparato la successiva.
Nei workflow tecnici più recenti viene conservato anche lo stato stabile precedente. Questo consente di applicare una modifica e poi riportare l'ambiente alla condizione attiva, sospesa o in manutenzione prevista, senza inventare uno stato finale uguale per tutti.
La profondità dei controlli dipende dal rischio del workflow. Una modifica di quota verifica formato, filesystem e limiti applicati. Un cambio PHP prepara una configurazione candidata, esegue i test del runtime e mantiene un rollback locale. Il restore, essendo distruttivo, esegue un preflight molto più ampio prima di rimuovere file o database.
Il preflight del ripristino mette in relazione:
La validazione non trasforma un import SQL in un'operazione matematicamente prevedibile: incompatibilità del motore o statement applicativi possono fallire dopo l'inizio. Serve a ridurre le cause evitabili e a non distruggere dati quando i prerequisiti noti non sono soddisfatti.
Dopo il claim, il nodo esegue le operazioni con gli strumenti adatti al componente: filesystem, web server, PHP-FPM, client database e helper dedicati. Le attività che non richiedono privilegi amministrativi vengono eseguite con l'identità del tenant quando possibile; quelle privilegiate devono ridurre il perimetro e verificare gli oggetti su cui operano.
Questa distinzione è particolarmente importante negli alberi modificabili dallo sviluppatore. Un processo root non può fidarsi di un controllo su un percorso e riaprire più tardi lo stesso nome come se nulla potesse essere cambiato. I flussi corretti usano operazioni relative a descriptor e no-follow, oppure delegano la lettura all'utente dell'ambiente.
Un codice di uscita positivo è necessario ma non sempre sufficiente. Fliclic controlla, in base al workflow, la presenza o assenza di database e utenti, la validità delle configurazioni, i permessi finali, l'applicazione della quota, gli hash degli artefatti, l'identità dei processi e la coerenza dello stato centrale.
Nel restore la verifica finale attraversa l'albero ricostruito, controlla il Project ID degli inode, confronta database attivi e fotografia e verifica che l'ambiente possa essere riaperto nella condizione prevista. Soltanto dopo la barriera di persistenza e la riapertura tecnica avviene la finalizzazione centrale.
Resta una finestra inevitabile tra sistemi diversi: una terminazione improvvisa dopo la riapertura e prima dell'ultimo aggiornamento remoto può lasciare un servizio tecnicamente disponibile con stato ancora “in esecuzione”. Fliclic documenta questo limite invece di descrivere un'atomicità che non esiste.
Alcuni workflow mantengono copie delle configurazioni e tentano un rollback se un test fallisce. Il cambio PHP, per esempio, conserva pool e vhost precedenti; l'aggiornamento PHP/FPM prepara un candidato e può ripristinare il file originario. Il backup STOP ripristina il vhost applicativo dopo la fase tecnica.
Questi meccanismi sono locali. Non esiste un commit unico tra database centrale, filesystem, MySQL locale, Apache e PHP-FPM. Un errore tardivo può lasciare risorse parziali e richiedere un intervento consapevole. La progettazione punta a ridurre e rendere diagnosticabili queste finestre, non a negarle.
