Todos los artículos Build in public

La ejecución que no esperó al wifi

Un portátil cerrado significaba una ejecución de visibilidad que se lanzaba igualmente y fallaba todas las consultas. Esta semana la aplicación aprendió a comprobar la conexión antes de empezar, y a detenerse y reintentar si la conexión se cae.

Moose
Moose
28 jul 2026 · 4 min de lectura
Ilustración cálida en gris carbón: un portátil cerrado sobre un escritorio de noche junto a la ventanilla de un tren, un símbolo de wifi dibujado como contorno vacío encima, luz suave de lámpara y un perro pequeño dormido bajo el escritorio.

TL;DR

  • Las ejecuciones de visibilidad programadas se lanzaban aunque la máquina estuviera sin conexión, así que un portátil cerrado significaba una ejecución que fallaba todas las consultas.
  • La aplicación ahora hace una comprobación real de conectividad antes de que empiece una ejecución programada, porque el sistema operativo indica "en línea" en el momento en que el portátil despierta, antes de que la conexión funcione.
  • Si la conexión muere en mitad de la ejecución, esta se detiene y el calendario reintenta cuando la máquina vuelve a estar en línea.
  • Las consultas fallidas quedan fuera de sus resultados, así que solo cuentan las respuestas reales.
  • También esta semana: una ejecución de visibilidad terminada puede pasarse directamente al chat de Moose para una conversación más larga sobre los resultados, y las personalizaciones del reproductor de audio ahora se guardan.

Programada para fallar

Hi, Moose comprueba su visibilidad en IA según un calendario: pregunta a los asistentes de IA que usan sus clientes sobre su sector y registra si usted aparece. La aplicación de escritorio hace las preguntas, desde su máquina.

Ahí es donde vivía el error. El calendario sabía cuándo tocaba una ejecución. No sabía si el portátil podía llegar a internet. Cierre la tapa, tome un tren, ábralo en algún sitio con un wifi que todavía no se ha decidido sobre usted, y una ejecución pendiente se lanzaba igualmente, hacía cada una de sus preguntas a una conexión muerta y fallaba absolutamente todas las consultas. Todo ese trabajo, nada que mostrar, y un desorden que el panel tenía que limpiar.

Una tarea programada que no levanta la vista de su lista de pendientes es un fallo muy reconocible. También es un fallo con arreglo.

Las barras de wifi no son internet

El arreglo obvio es "comprueba primero si estás en línea", y aquí está la parte que lo hizo interesante: el sistema operativo es un optimista. En el momento en que un portátil despierta, la interfaz wifi está activa y el sistema indica conectado, mientras el DNS y el enrutamiento todavía están buscando sus zapatos. Una ejecución lanzada en ese hueco falla exactamente igual que antes, con un icono de wifi verde mirando cómo pasa.

Así que la aplicación dejó de pedirle su opinión al sistema y empezó a comprobarlo por su cuenta. Antes de que empiece una ejecución programada, hace una petición real a dos puntos de conectividad muy conocidos, del mismo tipo que usa su portátil para detectar las páginas de acceso de las cafeterías, y se queda con la primera respuesta que llega. Si ninguno responde, todavía no hay ejecución. El calendario simplemente espera, y la ejecución se lanza cuando la conexión es real.

Parar, y luego volver a intentarlo

Las conexiones también mueren a mitad de ejecución. La ejecución ahora se da cuenta: si un par de consultas seguidas vuelven sin nada, verifica la conexión antes de gastar tiempo en el resto. Una sola comprobación puede tardar minutos en rendirse ante una conexión muerta, y una ejecución tiene muchas, así que darse cuenta pronto importa.

Si resulta que la máquina está sin conexión, la ejecución se detiene, aparta su pila parcial de fallos y reabre la ventana del calendario de hoy. Cuando usted vuelve a estar en línea, se lanza una vez y hace el trabajo como es debido. Y las consultas fallidas quedan fuera de sus resultados en cualquier caso, así que solo cuentan las respuestas reales.

Una ejecución con la que puede hablar

También esta semana: cuando una ejecución de visibilidad termina y usted quiere profundizar, puede pasársela al chat de Moose para seguir analizándola. Los resultados van con ella, y como la propia aplicación escribió ese primer mensaje, el chat se pone a trabajar directamente. De un gráfico a una conversación sobre el gráfico, en un paso.

Y una pequeña que mejorará en silencio el martes de alguien: si personaliza el reproductor de audio integrado de la función Listen, sus ajustes ahora se guardan. Configúrelo una vez, quédeselo.

FAQ

¿Cuál era el error de las ejecuciones programadas de visibilidad?

El calendario se cumplía sin importar si la máquina podía llegar a internet. En un portátil cerrado o recién despertado, la ejecución arrancaba, fallaba todas las consultas y no tenía nada real que mostrar.

¿Cómo comprueba ahora la aplicación que está en línea?

Hace una petición real a dos puntos de conectividad muy conocidos antes de que empiece una ejecución programada. La señal de conexión del propio sistema operativo no basta, porque indica conectado en el momento en que el portátil despierta, antes de que la conexión funcione.

¿Qué pasa si la conexión se cae en mitad de una ejecución?

La ejecución se detiene en lugar de arrastrar el resto de sus comprobaciones contra una conexión muerta. El calendario se reabre y la ejecución se lanza una vez cuando la máquina vuelve a estar en línea.

¿Las consultas fallidas afectan a mis resultados de visibilidad?

No. Una consulta que nunca obtuvo respuesta se registra como no disponible y queda fuera de sus resultados, así que solo cuentan las respuestas reales.

Moose
Moose
Hi, Moose

El que está bajo el escritorio durante todo esto.