Recordatorios de cita (cron diario)

petid-apipetid-client
actualizado 2026-09-02

Objetivo

Avisar al dueño el día antes de una cita, sin backend involucrado del lado clínica — es 100% autónomo del dominio appointments.

Cómo empieza

SendAppointmentRemindersTask.run(), @Cron(CronExpression.EVERY_DAY_AT_6PM) — sin trigger manual.

Pasos principales

1. Si env.ENABLE_CRON es falso, el método retorna sin hacer nada — ni loguea.
2. appointments.findScheduledBetween(mañana 00:00 UTC, mañana 23:59 UTC) — la query en Prisma filtra scheduledFor en ese rango y reminderSentAt: null. Ese segundo filtro es el dedup real, no una verificación aparte en memoria.
3. Por cada cita: busca la mascota y sus dispositivos, dispara push (sendToTokens) si hay al menos uno, y siempre marca reminderSentAt = now al final — haya o no haya dispositivos.
4. El code del push depende del estado: appointment-reminder-suggested si AppointmentStatus.SUGGESTED (la clínica sugirió la cita, el dueño no la agendó todavía), appointment-reminder-scheduled para cualquier otro estado.

Reglas de negocio

• El nombre findScheduledBetween es engañoso: no filtra por status en absoluto, solo por fecha + reminderSentAt: null. “Scheduled” se refiere a la fecha, no al AppointmentStatus.
• El dueño recibe como máximo un recordatorio por cita — el reminderSentAt se escribe en el mismo ciclo que se intenta el push, no en una confirmación de entrega.

Interacciones

Cron interno de petid-api → PushSender → notification-api → petid-client. No hay ida y vuelta con petid-crm.

Dónde seguir mirando

• petid-api/src/infrastructure/tasks/send-appointment-reminders.task.ts
• petid-api/src/infrastructure/persistence/appointments/prisma-appointment.repository.ts (findScheduledBetween)
• petid-api/src/infrastructure/config/env.config.ts → ENABLE_CRON (default false)

Casos especiales

• ENABLE_CRON es false por default. Un deploy nuevo sin esa variable seteada explícitamente no manda ningún recordatorio — y no hay ningún log ni error que lo delate, simplemente el cron corre y no hace nada.
• Una cita CANCELLED programada para mañana igual dispara el push (con code appointment-reminder-scheduled, ya que solo SUGGESTED tiene código propio) si nadie la puso en reminderSentAt antes — cancelar una cita no la excluye de este cron. Comparar con appointment-status-push.md: ese flujo sí filtra la transición a CANCELLED, este no filtra nada por status.
• Si una cita no tiene dispositivos registrados en el momento exacto del cron, pierde el recordatorio para siempre — reminderSentAt ya quedó seteado, así que aunque el dueño registre un dispositivo esa misma tarde, no hay una segunda pasada.