L’ANALISI
Hermes Agent 0.21.2: cosa cambia per state.db e profili
La patch interviene sui writer concorrenti, sul recupero SQLite e sui confini tra profili: è un aggiornamento operativo, non una nuova funzione da mostrare.
In breve: Conviene aggiornare soprattutto se si usano cron, dashboard o più profili: la release rimuove writer concorrenti su state.db, rende il recupero più prudente e chiude diversi percorsi di contaminazione tra profili. Un database già danneggiato richiede comunque diagnosi e recupero espliciti.
Perché state.db diventava fragile
La release attribuisce i problemi a più componenti che aprivano handle scrivibili o cancellavano lock POSIX mentre il gateway era attivo. La correzione sposta lo stato condiviso, apre la dashboard in sola lettura quando possibile e fa passare cron e doctor dal registro delle connessioni.
Danno FTS e corruzione non sono la stessa cosa
Un errore limitato all’indice full-text non deve bloccare l’intera conversazione. La patch classifica separatamente il danno FTS, consente la ricostruzione successiva e rende più conservativi checkpoint, quarantena e recupero.
Il confine tra profili
La release corregge lookup di sessioni, allow-list, credenziali, media e server MCP che potevano risolversi sul profilo predefinito. Il punto pratico è verificare che ogni gateway, callback e archivio resti associato al profilo richiesto.
Condizioni e limiti
Le note sono evidenza del maintainer e descrivono molte correzioni, ma non sostituiscono un test sul proprio filesystem, in particolare OpenZFS, WSL2 e installazioni multi-profilo. La patch non promette di riparare automaticamente ogni archivio già compromesso.
Checklist di aggiornamento e verifica
- Creare un backup coerente di state.db, file WAL e configurazione prima dell’aggiornamento.
- Annotare profilo attivo, HERMES_HOME e processi gateway o dashboard in esecuzione.
- Aggiornare alla release v0.21.2 tramite il percorso previsto dall’installazione.
- Eseguire hermes doctor e distinguere danni strutturali da problemi dell’indice FTS.
- Provare elenco, ricerca, export e ripresa di una sessione per ciascun profilo.
- Verificare che credenziali, media, allow-list e risultati MCP non attraversino i profili.
- Se il database era già danneggiato, usare prima la modalità di ispezione del recupero e conservare il backup.