davideandClaude Sonnet 5.5
8f25143aa5
- Spezza il registro delle decisioni in docs/decisions/DD-XXX.md, con indice - Ripulisce DATABASE.md dalla storia delle migration e aggiunge la sezione Lettura - Riduce PROJECT_STATE.md a una pagina; la procedura di allestimento passa in OPERATIONS.md - Aggiunge OPERATIONS.md, GLOSSARIO.md, trappole note e checklist in ARCHITECTURE.md - Sintetizza la copertura test di badge.md e documenta docs/archive - Allinea AGENTS.md, README.md e la regola Cursor (tolto l'obbligo di develop, in contrasto con DD-019) Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
56 lines
3.5 KiB
Markdown
56 lines
3.5 KiB
Markdown
# DD-037 — I promemoria evento ricordano di essere già stati generati
|
||
|
||
**Data:** 29 settembre 2026
|
||
**Stato:** Accettata
|
||
|
||
**Contesto**
|
||
I promemoria a 24 e a 3 ore (M17, DD-030) evitavano i doppioni con `ON CONFLICT DO NOTHING` sul
|
||
vincolo `UNIQUE (giocatore_id, evento_id, tipo)` di `notifiche_utente`: la riga della notifica
|
||
era l'unica traccia che il promemoria fosse già stato generato. Il giocatore però può eliminarla
|
||
(swipe o ×, DD-030). Senza più la riga, al giro successivo del job (ogni ora per il promemoria a
|
||
24 ore, ogni 15 minuti per quello a 3 ore, finché l'evento non inizia) il promemoria veniva
|
||
rigenerato come non letto. Con il canale email (DD-036) ogni rigenerazione accodava anche una
|
||
mail nuova: un giocatore che eliminava un promemoria ne riceveva una ogni ora fino all'inizio
|
||
dell'evento. Il difetto è stato trovato controllando la logica il 29/09/2026, il giorno in cui il
|
||
worker email è entrato in produzione, e riprodotto sul database locale.
|
||
|
||
**Decisione**
|
||
Un registro separato, `promemoria_eventi_generati` (migration `m23_promemoria_gia_generati`), con
|
||
una riga per `(giocatore_id, evento_id, tipo)` scritta dalla funzione `genera_promemoria_eventi()`.
|
||
La notifica in-app si crea solo per le righe **appena registrate**, quindi eliminarla non fa
|
||
ripartire nulla. Il registro è indipendente da `notifiche_utente`, senza policy per i client, e
|
||
sparisce con l'evento o con il giocatore (`ON DELETE CASCADE`). I promemoria già presenti al
|
||
momento della migration sono stati registrati come generati, altrimenti la prima notifica
|
||
eliminata dopo la migration sarebbe tornata come prima. Il vincolo `UNIQUE` di `notifiche_utente`
|
||
resta come seconda difesa. Cron, criteri di selezione, testi e destinatari sono invariati.
|
||
|
||
**Alternative scartate**
|
||
|
||
- Non eliminare davvero la notifica (nasconderla con un flag) → scartata: cambia il significato
|
||
dell'eliminazione per tutte le sorgenti, tocca la RLS e le query del client, e la tabella
|
||
crescerebbe di righe che il giocatore non vede più.
|
||
- Togliere l'eliminazione dai soli promemoria, lasciando «segna come letta» → scartata: a un
|
||
giocatore che vuole ripulire l'elenco resterebbero notifiche non eliminabili, incoerenti con
|
||
le altre.
|
||
- Un flag «già generato» sulla riga dell'evento → scartata: il promemoria è per giocatore, e chi
|
||
viene aggiunto ai convocati dopo deve comunque riceverlo.
|
||
- Confrontare `creato_il` o lo stato «letta» per capire se ricrearlo → scartata: non distingue
|
||
una notifica mai generata da una eliminata.
|
||
|
||
**Conseguenze**
|
||
|
||
- Eliminare un promemoria lo fa sparire per sempre, e non parte nessuna mail in più. Il numero
|
||
massimo di mail automatiche per giocatore ed evento resta due (24 e 3 ore).
|
||
- Una tabella in più, che cresce di una riga per giocatore, evento e tipo e si svuota con
|
||
l'evento.
|
||
- Se un evento viene spostato dopo che il promemoria è partito, non ne parte uno nuovo per la
|
||
data nuova: è lo stesso comportamento di prima, ora esplicito.
|
||
- `test/integration/promemoria-eventi.test.ts` è la definizione eseguibile: il promemoria
|
||
eliminato non ricompare, non riaccoda mail, i due tipi sono indipendenti, un convocato aggiunto
|
||
dopo lo riceve comunque, il registro non è leggibile né scrivibile da un client e sparisce con
|
||
l'evento. Sul database con la funzione vecchia il test fallisce.
|
||
|
||
**Riesame**
|
||
Se gli eventi potessero essere spostati con frequenza e servisse un nuovo promemoria per la data
|
||
nuova, il registro va agganciato anche alla data di inizio, oltre a giocatore, evento e tipo.
|