Distinguir los vuelos demo de los reales

Distinguir los vuelos demo de los reales

Alguien pasa por delante de la pantalla y comenta que los vuelos parecen equivocados, o inventados, o los mismos que ayer. Este artículo os enseña a demostrar si la pantalla está realmente con datos demo, enumera las cinco situaciones que los producen y —igual de importante— repasa los síntomas que parecen datos demo pero vienen de otra cosa. La mayoría de los avisos que nos llegan son del segundo tipo.

Empezad por la prueba, porque lleva un minuto y zanja la cuestión. Todo lo que viene después da por hecho que ya conocéis la respuesta.

La única prueba fiable

La pantalla obtiene sus vuelos de /api/flights/<hotelId>, y esa respuesta dice sin rodeos qué tipo de datos lleva. Abrid la URL de la pantalla en cualquier ordenador, pulsad F12, id a la pestaña Network, filtrad por flights, recargad la página y haced clic en la petición. En el cuerpo de la respuesta, mirad los campos del nivel superior:

Dos detalles de esta petición os despistarán si nadie os avisa. Primero, nunca falla. Incluso cuando la pantalla cae hasta los vuelos demo, la ruta responde con HTTP 200 y success: true, así que nunca veréis una fila roja en la pestaña Network: el repliegue es invisible desde fuera si no leéis el cuerpo. Segundo, los mensajes que registran ese repliegue se escriben en el servidor, no en el navegador, de modo que la pestaña Console no aporta nada útil para esta pregunta.

Por qué los vuelos en sí no os dicen nada

El instinto evidente es juzgar por lo que hay en la pantalla. Aquí no funciona, y conviene saber por qué antes de dedicarle veinte minutos.

Los vuelos demo son deliberadamente convincentes. Llevan aerolíneas reales y números con aspecto real —OS 501 de Austrian Airlines, LH 1234 de Lufthansa, LX 456 de Swiss, W6 2345 de Wizz Air— con terminal, puerta y cinta de equipajes rellenados. Un número de vuelo es, por tanto, la peor pista posible.

Sus horas tampoco son fijas. Cada vuelo demo se genera de nuevo contra el reloj del momento de la petición, así que una salida queda siempre a veinticinco o treinta y cinco minutos vista, miréis cuando miréis. La pantalla nunca parecerá congelada por su culpa. Sus estados también están mezclados: algunos están programados, uno va en vuelo con quince minutos de retraso y, en un panel de llegadas, algunos ya han aterrizado. No hay una delatora hilera de entradas idénticas y puntuales.

La marca Última actualización del pie es igual de inútil como prueba. Se fija cada vez que llega una respuesta, sin importar qué contenía.

Qué provoca realmente los vuelos demo

Son exactamente cinco casos. Nada más en el producto cambia la pantalla a datos demo.

Fijaos en lo que no está en esa lista. La ruta de vuelos nunca consulta vuestro estado de suscripción. Una suscripción caducada, cancelada o con pagos pendientes no cambia la pantalla a vuelos demo, y pagar una factura pendiente no cambiará lo que se ve. El estado de la suscripción gobierna el acceso a funciones —diapositivas adicionales, meteorología, analíticas, marca— y la API pública, no el panel de vuelos.

La insignia amarilla Modo Demo del pie de la pantalla está atada a demo: true, así que solo aparece en la pantalla demo. En los cuatro casos que de verdad os traen hasta aquí, la pantalla no lleva ninguna marca. Su ausencia no demuestra nada: usad la prueba de Network.

Síntomas que no son datos demo

Si la respuesta dice que los datos son reales y aun así la pantalla se ve mal, suele ser por uno de estos motivos.

Los vuelos son reales, pero antiguos. Cuando la llamada al proveedor de vuelos falla —una clave caducada, una caída del proveedor, un tiempo de espera agotado—, el sistema no salta directamente a datos demo. Primero sirve el último resultado correcto, que se guarda hasta veinticuatro horas. Así que la pantalla sigue mostrando vuelos auténticos de un aeropuerto auténtico, solo que cada vez más desfasados. Por eso una clave de API *inválida* se comporta de forma distinta a una *ausente*: una clave ausente os da vuelos demo de inmediato, mientras que una equivocada os da los vuelos reales de ayer hasta que esa caché se agota.

La pantalla parece no actualizarse. La frecuencia con la que se vuelven a pedir los datos de vuelo depende del plan: sesenta minutos en Basic, treinta en Pro, cinco en Premium. Una cuenta sin plan reconocido recibe sesenta minutos. En Basic, una hora sin cambios visibles es exactamente lo que hace el plan, y es la razón más frecuente por la que alguien concluye que la pantalla está atascada en datos prefabricados.

El aeropuerto es el equivocado, pero los vuelos son reales. Si un hotel no tiene aeropuerto configurado, la pantalla no recurre a datos demo: recurre a Viena y pide salidas reales de Viena. Los huéspedes que informan de vuelos hacia aeropuertos a los que nadie del edificio viaja suelen estar viendo esto. Los aeropuertos están en Portal → Aeropuertos, donde vuestro plan incluye uno y se pueden añadir más; cuál de ellos muestra cada pantalla se elige en el editor de pantallas, en Aeropuerto y hora.

La pantalla muestra la configuración de otra pantalla. El aeropuerto, el nombre del hotel y el diseño se configuran ahora pantalla por pantalla, y la URL lleva la pantalla a la que pertenece como ?display=<displayId>. Si abrís /display/<hotelId> sin ese parámetro, se cargará la pantalla activa que se configuró más recientemente: vuelos reales, correctos en sí mismos, pero del aeropuerto de otra pantalla. Copiad la URL desde el portal en lugar de escribirla: Portal → Pantallas tiene un icono de copiar en cada fila, y Portal → Pantallas → abrid la pantalla → Vista Previa & URL muestra la misma dirección en el campo URL de la Pantalla. Cuando hay un dominio propio verificado, esa dirección es simplemente https://<vuestro-dominio>.

La pantalla está vacía, no falsa. Una pantalla apagada con el icono de encendido de su fila en Portal → Pantallas devuelve un panel vacío marcado con inactive: true. No hay nada mal en el camino de los datos: la pantalla está apagada.

Mirad el portal antes de ir hasta la pantalla

Portal → Pantallas responde a «¿está esta pantalla mostrando algo actual?» más rápido que cualquier herramienta del navegador. Cada pantalla lleva un estado: En marcha, Sin conexión, Nunca abierta para una que existe en el portal pero cuya URL no se ha cargado nunca en un dispositivo, y Apagada para una que habéis desactivado.

Esas etiquetas se apoyan en una señal de vida que la pantalla envía cada cinco minutos, y una pantalla solo se da por desconectada tras doce minutos de silencio. El margen es deliberado —dos señales perdidas más un poco de holgura—, porque de lo contrario una sola petición perdida durante una recarga o un microcorte de red daría por caída una pantalla de recepción perfectamente sana. También significa que una pantalla que acabáis de desenchufar seguirá marcando En marcha durante unos minutos.

La facturación ya no está en la barra lateral: vive en el menú detrás de vuestro avatar, en Facturación, y allí se ve el estado de la suscripción. La página tiene un único botón, Gestionar Suscripción, que os lleva al portal de clientes de Stripe, donde ocurren las renovaciones, las cancelaciones y los cambios de tarjeta. Merece la pena si vuestra suscripción necesita atención de verdad; eso sí, no esperéis que cambie el panel de vuelos.

Instalaciones autoalojadas

Dos variables de entorno deciden si los vuelos reales son siquiera posibles. AVIATIONSTACK_API_KEY es la credencial del proveedor de vuelos y, sin ella, cada petición devuelve vuelos demo. POSTGRES_URL se comprueba aún antes: sin base de datos configurada, la ruta devuelve vuelos demo antes de buscar vuestro hotel.

Al proveedor de vuelos se le llama desde el servidor, no desde la pantalla. Un dispositivo de pantalla en la red del hotel solo necesita alcanzar lobbyflight.com por el puerto 443; nunca habla con api.aviationstack.com y no hay motivo para abrirle nada. El acceso saliente al proveedor hace falta allí donde se ejecuta la aplicación, y esa llamada va por HTTP simple en el puerto 80.

Una cosa más que conviene saber al autoalojar: si falta STRIPE_SECRET_KEY, la comprobación de funciones las da todas por disponibles. Eso resulta cómodo en local y confuso si intentáis reproducir los límites del plan de un cliente.

Confirmar que los datos reales también son correctos

Una vez que la respuesta muestra datos reales, queda la pregunta de si coinciden con la realidad. Abrid la web oficial del aeropuerto al que está ajustada la pantalla y comparad los números de vuelo con el panel. Vienen del flujo en tiempo real del proveedor y deberían cuadrar. Si cuadran pero las horas no, la causa es una zona horaria y no la fuente de datos.

Próximos pasos