# Bug que evito que se ejecutara el cron ## ¿Cómo se evidenciaba el bug? - Al intentar actualizar equip a través de docker-compose up, apareció el siguiente mensaje ![](https://i.imgur.com/9zo7b8W.png) ## Diagnóstico - De la imagen Aparece que al reiniciar la api se comienza a ejecutar el cron del día 2021-01-12. Lo cual no debiese ocurrir, ya que ese cron debió haber corrido a las 00:00 hrs de ese día - Lo siguiente se explica debido a que el cron tuvo un error interno cuando se ejecuto a las 00:00, por lo que no se registró su ejecución en la tabla version de la base de datos de beta, y quedó registrado solamente el cron anterior ejecutado correctamente (2021-01-11) - Se baja la BD al local del desarrollador, y se debuguea el cron. - El error, como dice el mensaje de arriba, era que el atributo `requestedUser` no puede ser undefined. Este error es debido a que la BD no puede almacenar valores indefinidos. - El error era producido dentro de la función finalPlanification que intentaba almacenar un borrador. Ya que la función que obtiene los pedidos enviados ayer`getRequestsSentYesterday` consideraba al borrador al tener un sendDate - El error se producía en planificationRequest al intentar pushear en planificationRequests un pedido de borrador, por lo que al intentar obtener `request.requestedUser` se definía como undefined ya que los borradores no tienen ese valor. - ¿Por qué el borrador tiene sendDate? - Porque el borrador fue creado asociado con una meta, la cual fue reactivada. Y al reactivar sus metas, por alguna razón, implica que a los pedidos del último ciclo se les asigna un sendDate. ## Pasos para reproducir el bug - Crear una meta - Crear un borrador asociado a esa meta - Cerrar la meta anticipadamente - Reactivar la meta - Cambiar de día. ## Alternativas de solución 1. No modificar sendDate de los pedidos al reactivar una meta. ¿por qué se definió así en un comienzo? ¿Qué consecuencias tare el no definir el sendDate?