55 lines
3.5 KiB
Markdown
55 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.
|