🔍 Análisis Técnico: CronJob de Kubernetes y Horarios Laborales¶

Propósito: Resolver la duda sobre la planificación segura de Kubernetes y cómo elude los fines de semana o casos fuera de horario.

1. El CronJob de Kubernetes (Localizado)¶

Se ha encontrado la manifestación exacta del CronJob en el core del clúster (Jenkins-X / Helm): Path: /home/amf/workspace.dkv/dkv-pet-cloud/versionStream/src/netcomp/charts/netcomp/values.yaml

cronjobs:
  job:
    curl-close-encounters:
      enabled: true
      schedule: "27 16 * * *"
      arguments:
      - -XPOST
      - "http://dkv-pet-proxy/api/v1/encounters/close_inactive"

Comportamiento: - Se ejecuta todos los días a las 16:27. - Llama ciegamente al endpoint /close_inactive de netcomp (vía proxy).

2. El Backend asume el Control Funcional¶

Al llamar a ese endpoint, netcomp delega la acción a dkv_telemed_import:close_inactive_encounters_fun/2 en Erlang. Este script hace lo siguiente:

QueueCfg = maps:get(QueueId, QueuesMap, #{}),
InactivityDays = maps:get(inactivity_days, QueueCfg, 0),
CloseUnassignedInactive = maps:get(close_unassigned_inactive, QueueCfg, false),
...

Condiciones del cierre por script: 1. Solo afecta a colas que tengan el flag correspondiente (en Erlang se asocia a horas o a inactivity_days mayor a 0). 2. Valida estrictamente que el tiempo sin mensajes del paciente (last_message_time) exceda el valor de inactivity_days.

3. El factor "Fuera de Horario y Viernes"¶

¿Cómo evita netcomp cerrar casos en fin de semana? Existen dos motores paralelos de inactividad que el equipo legacy (netcomp) fue montando con el tiempo:

Motor	Responsable	Mecanismo	Respeta Horarios?
Motor A: CronJob (Batch)	K8s + Endpoint BBDD	Un job diario de "barrido" cierra los que superen `inactivity_days`.	NO NATIVAMENTE. Si los N días caen en domingo, los cierra en domingo. A menos que la lógica del frontend limite la creación.
Motor B: DTM (Realtime)	Distributed Task Manager (`dkv_telemed_dtm.erl`)	En tiempo real. Suma `max_inactive_patient_time` a cada interaction.	SÍ. El DTM está diseñado para pausar el reloj si la cola tiene un calendario (horario de atención), retomándolo el lunes.

4. El Gran Riesgo Identificado por el Usuario ⚠️¶

Si desactivamos los motores nativos (seteando close_inactive_encounters=false y los tiempos a cero en la configuración de la Cola) para delegarlo todo a los Timers de Dapr en Pet Flows:

Problema: Un Timer de 24h en Dapr (Pet Flows) programado un viernes a las 18:00, va a expirar el sábado a las 18:00. Pet Flows mandará una notificación Push e incluso cerrará el caso en pleno fin de semana, perturbando la paz del paciente fura del horario de soporte de la doctora.

5. Propuestas de Resolución Arquitectónica para Pet Flows¶

Para mantener la regla fundamental de Zero-Erlang-Touch y no modificar el Core, Pet Flows necesita heredar la inteligencia de "Horarios" de la clínica.

Opcion A (Compleja): Pet Flows lee los Calendarios (Schedules)¶

Si la base de datos de PET Cloud (Postgres/ES) exporta un endpoint con los horarios comerciales de cada cola (GET /api/v1/queues/{id}/calendar), al recibir el webhook, el orquestador Jaraxa / Pet Flows utiliza un nodo especial "Wait (Business Hours)" en lugar de un "Wait (Raw)". El nodo calcula saltarse el fin de semana.

Opcion B (Específica): Dapr Cron Bindings Intersectados¶

En lugar de lanzar timers sueltos para los cierres, Pet Flows crea un CronTrigger en Dapr que corra de Lunes a Viernes a las 16:00. Cuando se ejecuta, mira el estado de espera y, si venció, envía las notificaciones. Así evitamos procesar eventos en Finde.

Opcion C (Pragmática MVP Backlog): Webhook Condenado vs Push Secundario¶

Mantener el max_inactive_patient_warning nativo para que calcule el tiempo real excluyendo festivos (apoyado en DTM). Sí, disparará el Push feo de Erlang, pero enviará un Webhook "en horario legal" y sin equivocarse de calendario. (Solo tolerable si Negocio asume que habrá un mensaje no customizado como preludio).

Conclusión para el Equipo: Es un hallazgo brillante. Pet Flows asume poder delegado pero debe adoptar la inteligencia del calendario. El Opcional A (Nodo "Esperar Días Laborables" consultando el microservicio de Calendario puro de Pet Cloud) es la forma canónica de resolverlo visualmente en Pet Flows.