Resolución de problemas

Los gráficos se quedan en blanco o informan de problemas de WebGL

Los gráficos se dibujan con WebGL. Si el navegador no puede crear un contexto WebGL, el gráfico informa de que no pudo inicializarse y te pide que actualices el navegador o actives la aceleración por hardware: esos dos pasos son la solución. Si el contexto gráfico se pierde más tarde, por ejemplo tras un reinicio de la GPU, una pestaña descartada o al reactivar un dispositivo móvil, el gráfico indica que el dibujado está en pausa y se reanudará cuando la GPU se recupere. La recuperación es automática: cuando el navegador restaura el contexto, el gráfico reconstruye sus recursos de GPU y vuelve a subir las velas actuales, así que no hace falta recargar la página. Si la propia reconstrucción falla, el gráfico se queda en pausa y el fallo se escribe en la consola del navegador.

Qué tiene que ofrecer tu navegador

Los gráficos de velas y los mapas de calor se dibujan sobre un contexto WebGL2. El renderizador pide al canvas específicamente webgl2 y lanza un error cuando el navegador no devuelve nada, que es el punto en el que el gráfico informa de que WebGL no pudo inicializarse y sugiere actualizar el navegador o activar la aceleración por hardware. No hay una vía de dibujado por software para las propias velas: la capa de anotaciones usa un canvas 2D normal, pero sin WebGL2 la serie de precios no se dibuja en absoluto. Un navegador que solo admite la primera generación de WebGL, o uno que funciona con la aceleración desactivada, produce por tanto un gráfico en blanco con ese mensaje exacto.

Cuando se crea un contexto y después se pierde —un reinicio del controlador de la GPU, una pestaña en segundo plano descartada, un dispositivo móvil que se reactiva—, el gráfico cancela el manejo por defecto de esa pérdida por parte del navegador, que es lo que hace posible la restauración automática, y pasa al estado de pausa. Al restaurarse, reconstruye sus recursos de GPU, invalida la versión de su búfer para que todas las velas se vuelvan a subir, y regresa al dibujado. Cada paso deja una línea en la consola del navegador con el prefijo [WebGLChart]: una para la pérdida, otra para la reconstrucción correcta y una línea de error si la reconstrucción falla. Esas tres líneas son la prueba más rápida que puedes incluir en un informe sobre un gráfico en blanco.

Redirecciones de inicio de sesión, avisos de Upgrade y funciones desactivadas

Abrir una página protegida sin la sesión iniciada te lleva a la página de inicio de sesión conservando tu destino, y te devuelve allí después; la misma situación en una petición de API responde 401 con UNAUTHORIZED. Si tienes la sesión iniciada pero tu plan no cubre la página, se te redirige a la página de Upgrade con el nivel requerido en la cadena de consulta, y la petición de API equivalente responde 402 con PAYMENT_REQUIRED más la clave de la función. El chat en vivo está protegido de la misma forma: en el nivel preview la página de Support muestra una llamada a mejorar el plan en lugar del chat. Una función desactivada por un operador responde 503 con KILL_SWITCH y una cabecera Retry-After.

Bloqueado, recortado y diferido: lo que no es un fallo

Dos señales visuales significan «tu plan no incluye esto», y ninguna es un error. Una superficie protegida se cubre con una capa de candado que intercepta tanto los clics del ratón como la activación por teclado y abre el diálogo de mejora de plan en lugar del enlace subyacente. Un widget de datos parcialmente visible recibe en cambio una píldora dorada en línea, que se usa cuando los datos están presentes pero reducidos, como un tick diferido o una profundidad de historial recortada. Si un gráfico muestra menos barras de las que esperas y lleva esa píldora, el historial se acortó a propósito y no se ha perdido.

El tiempo explica una tercera observación. Una barrera permanece indeterminada a propósito hasta que se cargan tus permisos: hasta entonces está oculta e inerte, para que quienes pagan nunca vean un destello de estado bloqueado antes de que se desbloquee. La consecuencia visible es que una casilla protegida puede quedarse vacía un instante justo después de cargar la página. En el servidor, la misma política responde a las peticiones de API con 402 y una carga útil que nombra la clave de la función y el nivel requerido, mientras que una navegación de navegador se redirige a la página de Upgrade con el origen, la ruta original y el nivel requerido en la cadena de consulta, y por eso la página de Upgrade puede decirte exactamente qué intentaste abrir.

Los códigos de error que lleva una respuesta de la API

Toda respuesta de la API propia de la app tiene una forma fija. Un éxito lleva success: true, una carga útil data y una marca de tiempo. Un fallo lleva success: false y un objeto error con un code legible por máquina, un message legible por personas y, opcionalmente, un target que nombra el campo problemático, un objeto details con contexto adicional y un doc_url. Cita el code cuando informes de un problema: el code es estable, la redacción del message no. Existen doce códigos, y cada uno está ligado a un único estado HTTP.

Dos formas de respuesta quedan fuera de ese conjunto. Los endpoints más antiguos responden con un sobre heredado de code, msg, data y success, donde code es una cadena numérica agrupada por clase: 10xxx para problemas de entrada, 20xxx para autenticación, 30xxx para autorización, 40xxx para recursos ausentes o en conflicto, 50xxx para fallos de servidor y 60xxx para servicios de origen. Los problemas de base de datos se traducen antes de llegarte: una conexión perdida se convierte en 503 con "Database temporarily unavailable", una consulta que supera su límite de tiempo se convierte en 504 con "Request timed out", un duplicado se convierte en 409 y una violación de restricción se convierte en 400. Los dos primeros merecen un reintento; los dos últimos se repetirán hasta que cambie la entrada.

• BAD_REQUEST — 400. La petición estaba mal formada. Revisa los parámetros que enviaste.
• VALIDATION_ERROR — 400. Una entrada no superó la validación; la respuesta la nombra en target.
• UNAUTHORIZED — 401. No hay sesión válida. Inicia sesión y repite la petición.
• PAYMENT_REQUIRED — 402. Con sesión iniciada, pero el plan no lo cubre. details lleva featureKey, requiredTier y, en las barreras de dominio, requiredDomain.
• FORBIDDEN — 403. Autenticado pero sin permiso. El motivo exacto se mantiene deliberadamente en el servidor.
• NOT_FOUND — 404. No existe ese recurso en esa dirección.
• CONFLICT — 409. El recurso cambió por debajo de ti, o ya existe. Recarga y reintenta.
• PAYLOAD_TOO_LARGE — 413. El cuerpo de la petición supera el tamaño aceptado.
• RATE_LIMITED — 429. Demasiadas peticiones. La respuesta lleva Retry-After, X-RateLimit-Limit y X-RateLimit-Remaining; los endpoints de IA tienen su propio presupuesto aparte y responden con el código específico AI_RATE_LIMITED.
• INTERNAL_ERROR — 500. Un fallo inesperado del servidor. Infórmalo con tu Error ID.
• UPSTREAM_ERROR — 502. Falló un servicio del que depende el endpoint. Reinténtalo más tarde.
• SERVICE_UNAVAILABLE — 503. Temporalmente no disponible. Ten en cuenta que una función desactivada a propósito usa otro cuerpo de 503, descrito más abajo.

Kill switches: quién apaga una función y durante cuánto tiempo

Un kill switch es un interruptor de apagado para una función concreta, accionado por el equipo de Athenum y no por ti, y es la razón de que una página pueda ser inaccesible mientras el resto de la app está sana. Dos situaciones distintas producen el mismo 503. Si la función está apagada porque su backend todavía no se ha publicado, la página de error dice «Coming Soon» y explica que la función está en desarrollo. Si un operador apagó una función que funcionaba, la página dice «Temporarily Unavailable». Ambas respuestas se identifican con el código KILL_SWITCH y un nombre público estable de la función, como funding-heatmap o cme-detector.

La respuesta te dice cuánto esperar. Cada interruptor lleva su propio valor de Retry-After: 60 segundos para la Funding Heatmap, 1800 segundos para el CME Detector y 300 segundos para cualquier función sin un ajuste explícito. Quienes llaman por la API reciben la misma información como application/problem+json, incluida una marca defaultKilled que distingue el caso de función no construida del caso de decisión del operador. El propio 503 nunca se cachea, y las respuestas correctas en endpoints conmutables se limitan a diez segundos de caché, así que un cambio de interruptor te llega rápido; una caché compartida todavía puede servir la respuesta anterior durante unos quince segundos tras el cambio.

Una ruta apagada normalmente no es accesible haciendo clic. Las rutas que un interruptor bloquea por completo se filtran de las tarjetas de la página de inicio y se ocultan de la paleta de comandos, así que el 503 lo ven sobre todo quienes usan un marcador, un enlace directo o la API. No todos los interruptores bloquean una ruta: algunos cambian el comportamiento en su sitio, y por eso una función puede verse afectada sin que ninguna página devuelva 503. Las páginas de kill switch no llevan Error ID, porque la respuesta es una decisión deliberada y no un incidente, y no se inventa ningún identificador para rellenar el campo.

Mantenimiento de todo el sitio frente a una única función que falla

Una ventana de mantenimiento planificada se ve distinta de cualquier otro fallo. En lugar de la página de error habitual recibes un documento independiente encabezado con «We'll be back soon», sin navegación, sin Error ID y sin enlace a soporte. Se sirve con HTTP 503 y un Retry-After de una hora. La página es totalmente autónoma —sus estilos y su logotipo están incrustados y no hace ninguna llamada de red—, así que se sigue dibujando aunque el backend, la base de datos y la analítica estén inaccesibles. También está marcada como no indexable, para que los buscadores traten la caída como algo temporal.

La barrera es deliberadamente estrecha. Solo sustituye las peticiones de página del navegador: peticiones GET o HEAD que piden HTML. Las llamadas a la API bajo /api/ pasan de largo, igual que los endpoints de salud del contenedor y cualquier petición de scripts, estilos o fuentes. Una consecuencia que conviene conocer: durante el mantenimiento, un cliente de API o una integración incrustada pueden seguir funcionando con normalidad mientras el navegador muestra la página de mantenimiento. Si ves «We'll be back soon», todo el sitio está afectado; si ves una página de error 503 que nombra una función, solo lo está esa función.

Leer un panel vacío: la insignia nombra el fallo

Los paneles de las páginas macro llevan una pequeña insignia en la esquina, y esa insignia es la forma más rápida de distinguir una caída de una fuente de datos tranquila. Cinco de los estados de la insignia describen datos reales y dos describen el propio panel. Como la insignia se deriva de las mismas reglas de frescura que el panel usa para dibujar, no puede afirmar un estado que los datos no respaldan: un panel sin nada que mostrar nunca se etiqueta como STALE, y un valor ausente nunca se sustituye por una cifra de relleno.

Las envolturas a nivel de panel añaden una segunda capa de información. Una primera carga en curso dibuja un esqueleto sin veredicto y sin texto. Una lectura que falló en el transporte dibuja una tarjeta de error con el texto «Fleet read failed — the source may still be live. Retry to reload.» y un botón de reintento: la fuente puede estar perfectamente sana y reintentar es la respuesta correcta. Una lectura que funcionó pero no devolvió filas dibuja «Awaiting Fleet-Bridge» con la insignia UNAVAILABLE. Esas dos se parecen y significan cosas opuestas: la primera es un problema de conexión que puedes reintentar, y la segunda significa que la serie todavía no ha empezado a fluir.

Los paneles de TradeFI informan del motivo con palabras en lugar de con una insignia. Cuando falló el proveedor de datos, el panel dice que los datos no están disponibles temporalmente. Cuando el proveedor respondió sin nada, dice que no hay datos disponibles para ese símbolo. La propiedad institucional añade un tercer caso: una nota que explica que la vista es un subconjunto oficial de instituciones seguidas y que es representativa, no exhaustiva; eso es una declaración de alcance, no un fallo. Las listas de comparables se comportan igual y nombran una fuente no habitual en una nota sobre el panel cuando se ha usado alguna.

• LIVE — una observación intradía o en tiempo real dentro de su cadencia esperada.
• EOD — un cierre de periodo honesto para una serie diaria, semanal, mensual o trimestral.
• STALE — un valor real, pero más antiguo que la cadencia de actualización esperada de la serie.
• FALLBACK — datos en caché del último valor bueno conocido, que explícitamente no son el valor actual.
• MODEL — una heurística calculada o una construcción de Athenum, no una observación directa.
• UNAVAILABLE — el panel está en estado de error y no se dibuja nada.
• LOADING — la primera carga sigue en curso y la frescura todavía no está determinada.

Informar de un problema: tu Error ID

Cuando una petición falla, la página de error muestra el estado HTTP, un título breve y —cuando se ha generado uno— un Error ID. Ese identificador se acuña para tu incidente concreto y se adjunta al informe de error registrado, así que soporte puede encontrar exactamente tu caso. Usa el botón de copiar que hay a su lado y después elige «Chat with support»: el enlace lleva el Error ID hasta la página de soporte. Al informar, incluye el Error ID, la dirección de la página y qué estabas haciendo. No todos los errores tienen uno: para una función desactivada temporalmente no se inventa ningún relleno, así que el campo simplemente no aparece.

Adónde va tu Error ID después de copiarlo

El identificador de la página de error se acuña en el servidor, una vez por incidente, en el momento en que se captura el fallo. El servidor escribe una entrada de registro que contiene ese identificador junto con el estado HTTP, el nombre del error, la ruta de la petición, el método de la petición y una marca de tiempo; en producción la entrada omite deliberadamente las trazas de pila y el detalle interno. El mismo identificador se adjunta al incidente enviado al sistema de seguimiento de errores, así que soporte puede correlacionar tu copia del identificador con el fallo registrado. Las peticiones que simplemente dan con una página inexistente son la excepción: siguen recibiendo un identificador, pero no se reenvían al seguimiento de errores.

Lo que recibe de vuelta el navegador es intencionadamente escueto —un mensaje genérico más el identificador— para que no se filtre ningún detalle interno por la página. Pulsar «Chat with support» lleva el identificador consigo: el enlace abre la página de soporte con un tema de incidente, el Error ID y una solicitud de abrir el chat, en lugar de lanzar un widget de chat en la página que falla. Si el botón de copiar parece no hacer nada, la escritura en el portapapeles fue rechazada —ocurre en orígenes no seguros o cuando se deniega el permiso de portapapeles— y el fallo queda registrado en la consola del navegador; en ese caso, selecciona el identificador a mano.

Que el chat en vivo esté realmente disponible en la página de soporte depende de tres comprobaciones hechas antes de que se dibuje la página. El chat requiere un plan de pago: en el nivel preview la página muestra un aviso de mejora de plan en su lugar. El chat también se retiene mientras el interruptor del mensajero de soporte está apagado, y mientras la petición necesita un consentimiento que no se ha registrado, lo que ocurre con las peticiones que parecen europeas, británicas o suizas, y con las peticiones que no llevan ninguna señal de país, ya que la comprobación falla del lado seguro. En todos esos casos la página sigue ofreciendo el correo y la comunidad de Discord, y esos dos están siempre presentes sea cual sea el plan.

Qué comprobar antes de informar de un problema

Casi todo lo que te preguntaría soporte ya está visible en la pantalla. Las comprobaciones de abajo llevan menos de un minuto y convierten un «está roto» en un informe sobre el que se puede actuar. Trabaja de fuera hacia dentro —todo el sitio, luego la página, luego el panel—, porque cada capa tiene un responsable distinto y una solución distinta. Nada de esto requiere herramientas de desarrollador salvo los dos puntos que las mencionan explícitamente.

• Determina el alcance. ¿Está afectada cada página, una página o un panel dentro de una página que por lo demás funciona? «We'll be back soon» significa todo el sitio; una página 503 que nombra una función significa solo esa función.
• Lee el texto literalmente. «Coming Soon» y «Temporarily Unavailable» son situaciones distintas aunque ambas sean 503, y los textos de panel «Fleet read failed» y «Awaiting Fleet-Bridge» significan cosas opuestas.
• Busca una insignia. LOADING, STALE, FALLBACK y UNAVAILABLE describen cada una una condición distinta, y un candado o una píldora dorada significan un límite del plan y no un fallo.
• Reintenta una vez después de esperar. Las respuestas temporales indican su propia ventana de reintento en la cabecera Retry-After, visible en el panel de red del navegador; reintentar antes suele devolver la misma respuesta.
• Para un gráfico en blanco, abre la consola del navegador y busca líneas con el prefijo [WebGLChart]; después confirma que el navegador está actualizado y que la aceleración por hardware está activada.
• Copia el Error ID si se muestra alguno. Si el botón de copiar no hace nada, selecciónalo manualmente: el navegador puede rechazar la escritura en el portapapeles.
• Anota la dirección de la página, la hora y lo que hiciste justo antes del fallo. El Error ID identifica el incidente; esos tres datos identifican qué intentabas conseguir.

Códigos de error del collector

El collector de datos de futuros etiqueta cada fallo con un código estable, y ese código aparece entre corchetes allí donde se muestra o se registra el texto del error. Son identificadores del backend: ver uno en una respuesta de soporte o en una nota de estado te dice qué etapa falló y si el collector reintentó, recurrió a otra fuente o se rindió.

Códigos de error de Volume Delta

El endpoint de Volume Delta devuelve un código con prefijo VDLT_ y una pista. Los errores reintentables son transitorios: la misma petición puede funcionar poco después; los demás exigen cambiar la propia petición.

Sigues atascado

Contacta con soporte desde dentro de la app. No hay ningún objetivo de nivel de servicio publicado, ni cifra de disponibilidad, ni tiempo de respuesta garantizado, así que esta página no declara ninguno.