OpenClaw · Le risposte non arrivano in chat: il turno viene riavviato e il testo non entra nella coda di consegna
→ Provocare il riavvio di proposito (messaggio nuovo mentre un turno lungo e' in corso) e verificare la perdita; poi nel codice del gateway far si' che un turno…
⚠ nel campo c'è un verbale di 46 parole, non una riga: qui sopra c'è l'inizio, il resto sta nel diario. Il dato andrebbe riscritto (lavoro sui CSV, non su questa pagina).
▸ apri il diario del campo▾ richiudi il diario
Provocare il riavvio di proposito (messaggio nuovo mentre un turno lungo e' in corso) e verificare la perdita; poi nel codice del gateway far si' che un turno riavviato consegni comunque il testo prodotto, o almeno che il canale riceva un avviso visibile invece del silenzio.
Osservato il 01-02/09/2026 in #romeo-bs2: 4 risposte su 8 mai uscite. CAUSA (prova nei log del gateway, openclaw-2026-09-02.log): se un secondo evento arriva mentre il turno precedente e' ancora in esecuzione - altro messaggio di Ettore, o avviso interno di comando interrotto -…
▸ continua a leggere (300 parole)▾ richiudi il diario
Osservato il 01-02/09/2026 in #romeo-bs2: 4 risposte su 8 mai uscite. CAUSA (prova nei log del gateway, openclaw-2026-09-02.log): se un secondo evento arriva mentre il turno precedente e' ancora in esecuzione - altro messaggio di Ettore, o avviso interno di comando interrotto - la sessione live viene chiusa con reason=restart e il turno visibile parte senza testo: WARN 'visible channel turn dispatched with no queued reply payloads' 4 volte oggi (08:41:20, 08:46:51, 09:44:18, 10:00:06); alle 09:44:12 turno chiuso a outBytes=0 con activeSessions=2. Innesco: turni lunghi (277 e 208 secondi misurati) dovuti a ricerche a tappeto sul disco. Mitigazione gia' adottata: ricerche solo in cartelle mirate. Gateway sano (acceso dal 26/08, health 200 in 27 ms). Scheda completa: REGISTRO_GUASTI/2026-09-02_risposte-perse-turno-riavviato.md SECONDA EVIDENZA, PIU' GRAVE (02/09 sera, sessione Archimede su a152): non si e' perso un messaggio, si sono pestati i file DUE TURNI DELLA STESSA SESSIONE. Il brief arrivato via sessions_send mentre il turno era in corso ha aperto una seconda esecuzione dello stesso task: ha ricostruito il mazzo di carte a meta' del giudizio in cieco (132 -> 144 carte, ore 19:24:38), cancellato e rigenerato le immagini, e sovrascritto il file dei giudizi facendo perdere 18 carte. Recuperato tutto (le immagini erano state copiate un minuto prima), ma il danno peggiore e' un altro: il turno gemello ha COMMITTATO un avviso in cui dichiarava che 3 giudizi su 10 erano inventati - falso, aveva verificato contro le immagini del mazzo sbagliato. Verificato da Romeo riaprendo la carta C095: e' davvero BLUEBELLS XVII firmata JESS, come diceva il giudizio accusato. Un'accusa falsa e committata invalida una misura vera per chiunque la legga dopo. Rettifica scritta dentro l'avviso senza cancellare nulla (commit 359f374). Rimedio locale gia' applicato: cieco.py rifiuta di ricostruire un mazzo che esiste gia'. Il rimedio di sistema e' questo task.
- nessun sottotask — aggiungine uno qui sotto
da definire
da definire
da definire
da definire