tcef-notifications/docs/rollout.md

Plan de puesta en marcha (rollout) — fase 1a

Regla de oro: nunca se salta un modo, y ningún canal pasa a full sin confirmación explícita del usuario. El riesgo nº1 es spamear a los usuarios.

Modos (env MODE)

Modo	Envía	Para qué
dry-run	no	calcula el payload, resuelve destinatario, loguea. Detecta errores de datos/plantillas sin tocar a nadie. No reserva en notification_sends.
shadow	no	igual que dry-run pero pensado para correr ≥1 día en paralelo con el sistema viejo y comparar decisiones (logs estructurados).
canary	solo cohorte	envía únicamente a CANARY_USER_IDS / CANARY_SUBS_IDS (dispositivos/suscripciones propias).
full	todos	operación normal.

Salvaguardas activas en todos los modos: KILL_SWITCH=1 (parada total), límite LIMIT_PER_USER_DAY, circuit breaker LIMIT_MAX_PER_BATCH, idempotencia persistente notification_sends (único por notificationId+channel).

Exclusión mutua por canal (obligatoria)

El sistema viejo (Meteor) y el nuevo jamás deben enviar por el mismo canal a la vez. Se controla con:

• Meteor (todos-contra-el-fuego-web): settings.private.notifDisabledChannels, un array con "mobile" y/o "web". Si un canal está ahí, el observer/cron viejos lo ignoran (guard en notificationsProcess.js). Cambio reversible sin desplegar código: editar settings y reiniciar el proceso Meteor.
• Servicio nuevo (OWNED_CHANNELS): fcm y/o email. Solo procesa los que posee.

Mapa de canales: mobile ↔ fcm, web ↔ email.

Orden seguro de cutover de un canal: (1) añadir el canal a notifDisabledChannels en Meteor y reiniciar → el viejo deja de enviarlo; (2) confirmar en logs que el viejo ya no lo toca; (3) añadir el canal a OWNED_CHANNELS del servicio y subir el modo. Nunca al revés.

Secuencia (por canal, empezando por FCM)

FCM es el primer cutover y el más seguro: el canal FCM del viejo está muerto desde jun-2024 (API legacy GCM apagada → 404), así que no hay envío real que solapar. Ver plan-modernizacion/ESTADO.md.

Paso 0 — Infra en shiva (una vez)

1. Node 22 standalone (nvm o binario), no el Node 8 del sistema.
2. Redis local (apt install redis-server o binario/contenedor).
3. Clonar el repo, npm ci && npm run build.
4. Config desde el repo privado tcef-private-config:
   • MONGO_URL (rsmain, db fuegos), MAIL_URL, GMAPS_KEY, FIRE_ICON_URL, ROOT_URL.
   • Service account de Firebase (FCM_SERVICE_ACCOUNT=/ruta/al.json) — descargar de la consola Firebase del proyecto org.comunes.fires (angular-cosmos-108908) → Configuración → Cuentas de servicio → Generar clave privada. Guardar solo en el repo privado / disco de shiva.

Paso 1 — dry-run FCM (unos ciclos)

MODE=dry-run OWNED_CHANNELS=fcm KILL_SWITCH=0

• Corre varios imports NASA (cada 15 min). Verifica en logs: payloads bien formados, cuántos users sin token, cuántos con token. No se envía nada.
• Criterio de avance: sin errores de datos/plantilla; volumen esperado.

Paso 2 — shadow FCM (≥1 día)

MODE=shadow OWNED_CHANNELS=fcm

• Compara decisiones con el sistema viejo (que en FCM no envía nada real igual).
• Criterio de avance: sin discrepancias inesperadas; sin duplicados en notification_sends.

Paso 3 — cutover + canary FCM (dispositivos propios)

1. En Meteor: notifDisabledChannels: ["mobile"], reiniciar tcef_web*.
2. Verificar que el viejo ya no procesa mobile.
3. Servicio:

   MODE=canary OWNED_CHANNELS=fcm CANARY_USER_IDS=<tu userId> FCM_SERVICE_ACCOUNT=...
   

4. Instala la app Flutter en un dispositivo propio con sesión iniciada, genera un fuego sintético cerca de tu suscripción → debe llegar la push (formato e idioma correctos). Verifica notification_sends (status sent) y logs de firebase-admin.
5. Simulacro de idempotencia: mata el worker a mitad de batch y reinícialo → cero reenvíos (comprobar notification_sends).

• Criterio de avance: push llega bien a la cohorte varios días, sin duplicados.

Paso 4 — full FCM (requiere confirmación explícita del usuario)

MODE=full OWNED_CHANNELS=fcm

• Los fireBaseToken llevan ~2 años sin uso → alta tasa de token muerto en el primer envío. Es esperado: se purgan (fireBaseToken=null), no se reintenta.
• Vigilar el circuit breaker y el límite por usuario/día.

Paso 5 — email (repetir la secuencia, solo tras FCM estable)

• dry-run → shadow (aquí el viejo SÍ envía email, así que el shadow es crítico: comparar a quién marcó el viejo como emailNotified vs. a quién enviaríamos, volcar discrepancias) → cutover (notifDisabledChannels: ["mobile","web"] en Meteor) → canary (buzón de test vía MAIL_REDIRECT_TO) → full (con confirmación).

Rollback (por canal)

1. Servicio: KILL_SWITCH=1 (parada inmediata) o quitar el canal de OWNED_CHANNELS.
2. Meteor: quitar el canal de notifDisabledChannels, reiniciar → el viejo reasume ese canal.
3. Nada se pierde: los docs pendientes siguen en notifications con notified/emailNotified sin marcar.

Checklist de verificación (por paso)

• Tests en verde (npm test).
• dry-run: payloads OK, sin errores, volumen esperado.
• shadow ≥1 ciclo NASA real sin discrepancias ni duplicados.
• Exclusión por canal confirmada (viejo no toca el canal migrado).
• Canary: entrega correcta a cohorte propia, formato/idioma OK.
• Simulacro kill-a-mitad-de-batch → cero reenvíos.
• Confirmación explícita del usuario antes de full.