Ricevute di pubblicazione che tutelano le chat di supporto realtime

Un “{ ok: true }” in una chat di supporto non basta: non dice quale evento è stato accettato, per chi, né da dove riprendere dopo una riconnessione¹.

L’acknowledgement deve legare cinque elementi: principale autenticato, conversazione, ID evento, tipo di evento e posizione di sequenza accettata. Il server deve ricavare l’attore dalla sessione autenticata, non fidarsi di un actorId nel payload. Deve autorizzare l’attore contro la conversazione prima di accettare l’evento. Deve restituire l’ID generato dal client per far combaciare la ricevuta con la publish in volo¹.

La ricevuta non deve promettere ciò che non certifica. “Accettato” significa entrato nel log durevole, non “renderizzato nel browser dell’agente” né “letto dallo studente”. Quei passaggi sono eventi separati. La distinzione regge quando due tab del supporto sono aperti, un device mobile si riconnette tardi o un agente trasferisce la conversazione. Un’unica azione di trasporto non può certificare tutti quegli esiti¹.

I tipi di eventi vanno separati. Indicatori di digitazione effimeri, messaggi del cliente e posizioni di lettura hanno contratti diversi. Gli indicatori possono scadere e sparire. Non vanno riprodotti al reconnect. I messaggi e le posizioni di lettura richiedono ID durevoli, controlli di autorizzazione, retry idempotenti e backfill a cursore¹. In un contesto edtech, questo scinde un “l’agente sta scrivendo” a basso costo e temporaneo dalla richiesta di aiuto reale che deve restare disponibile anche dopo lo sleep di un laptop¹.

Esempio. Uno studente invia l’evento evt_01JCHAT8M4 nella conversazione conv_algebra_42. La risposta di accettazione ripete l’ID e assegna il cursore 1842. Un retry con lo stesso ID deve risolversi nello stesso evento accettato, non creare un duplicato. Un agente che legge fino al cursore 1842 pubblica un evento di posizione di lettura, legato a quell’agente e a quella conversazione. La posizione avanza in modo monotono: un aggiornamento vecchio e ritardato non deve riportarla indietro. I valori sono illustrativi, non dati di produzione¹.

Scrivete la macchina a stati prima di scegliere il trasporto. Un ciclo utile è: pending, accepted, delivered, read. Ogni transizione appartiene a un’osservazione diversa. Evitate un callback ambiguo che cambia significato a seconda del tempo¹.

I controlli di sicurezza circondano la transizione al durevole. Autenticate la connessione. Autorizzate ogni publish. Limitate tipi di evento e dimensioni del payload. Rifiutate cambi di conversazione dopo l’autorizzazione. Applicate rate limit per principale e conversazione. Registrate un log di audit, senza copiare i corpi dei messaggi sensibili. La cifratura in transito protegge il canale, ma non sostituisce l’autorizzazione a livello di oggetto¹.

Il reconnect è la prova operativa. Il client conserva l’ultimo cursore applicato, si riconnette con quel cursore, scarica gli eventi successivi, li applica in ordine, poi entra nel flusso live. Il server deve definire il confine tra backfill e subscription in modo da non perdere né applicare due volte lo stesso evento. La regola più semplice lato client è l’idempotenza per ID evento immutabile: i duplicati a livello di trasporto si annullano prima di cambiare lo stato UI¹.

Testate le finestre di race. Aprite una subscription, mettete in pausa la consegna, pubblicate eventi ai cursori 1843 e 1844, riconnettete da 1842, poi togliete la pausa mentre il backfill è in corso. La timeline finale deve mostrare ogni evento una sola volta e fermarsi a 1844. Ripetete invertendo l’ordine tra live e backfill. Fate anche scadere il cursore e verificate una risposta di resync esplicita¹.

I canali dati WebRTC, pur offrendo ordering predefinito, limiti di ritrasmissione, bufferedAmount ed errori, non provano il superamento del controllo permessi né l’ingresso nel log durevole secondo il prodotto: serve comunque una ricevuta applicativa con claim precise, a prescindere dal trasporto e dalla raccomandazione W3C¹.

Il tracciamento di delivery e lettura raccoglie metadati di attività: tenete solo lo stato minimo utile al workflow, fissate una retention, limitate chi può interrogarlo e adeguate il testo UI al fatto registrato, per esempio non mostrare “visto” quando avete solo la consegna di socket¹.