CRAPP/docs/decisions/DD-037.md

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.