Fehlerbehebung

Charts bleiben leer oder melden WebGL-Probleme

Charts werden mit WebGL gezeichnet. Kann der Browser überhaupt keinen WebGL-Kontext erzeugen, meldet der Chart, dass die Initialisierung fehlgeschlagen ist, und bittet darum, den Browser zu aktualisieren oder die Hardwarebeschleunigung einzuschalten — diese beiden Schritte sind die Abhilfe. Geht der Grafikkontext später verloren, etwa nach einem GPU-Neustart, einem verworfenen Reiter oder dem Aufwachen eines Mobilgeräts, meldet der Chart, dass das Rendern angehalten ist und fortgesetzt wird, sobald sich die GPU erholt. Die Erholung läuft automatisch: Stellt der Browser den Kontext wieder her, baut der Chart seine GPU-Ressourcen neu auf und lädt die aktuellen Kerzen erneut hoch, ein Neuladen der Seite ist also nicht nötig. Scheitert der Neuaufbau selbst, bleibt der Chart angehalten und der Fehler wird in die Browserkonsole geschrieben.

Was der Browser mitbringen muss

Die Kerzen- und Heatmap-Charts werden auf einem WebGL2-Kontext gezeichnet. Der Renderer fragt die Canvas ausdrücklich nach webgl2 und erzeugt einen Fehler, wenn der Browser nichts liefert — an dieser Stelle meldet der Chart, dass WebGL nicht initialisiert werden konnte, und schlägt vor, den Browser zu aktualisieren oder die Hardwarebeschleunigung einzuschalten. Für die Kerzen selbst gibt es keinen Software-Zeichenweg — die Anmerkungsebene nutzt eine gewöhnliche 2D-Canvas, aber ohne WebGL2 wird die Preisreihe gar nicht dargestellt. Ein Browser, der nur die erste WebGL-Generation unterstützt, oder einer mit abgeschalteter Beschleunigung, erzeugt daher einen leeren Chart mit genau dieser Meldung.

Wird ein Kontext erzeugt und später verloren — ein Neustart des GPU-Treibers, ein verworfener Hintergrundreiter, ein aufwachendes Mobilgerät —, unterbindet der Chart die Standardbehandlung des Verlusts durch den Browser, was die automatische Wiederherstellung überhaupt erst möglich macht, und wechselt in den angehaltenen Zustand. Bei der Wiederherstellung baut er seine GPU-Ressourcen neu auf, verwirft seine Pufferversion, sodass jede Kerze erneut hochgeladen wird, und zeichnet wieder. Jeder Schritt hinterlässt eine Zeile in der Browserkonsole mit dem Präfix [WebGLChart]: eine für den Verlust, eine für den erfolgreichen Neuaufbau und eine Fehlerzeile, wenn der Neuaufbau scheitert. Diese drei Zeilen sind der schnellste Beleg für eine Meldung über einen leeren Chart.

Anmeldeumleitungen, Upgrade-Hinweise und abgeschaltete Features

Wird eine geschützte Seite im abgemeldeten Zustand geöffnet, führt der Weg zur Anmeldeseite, wobei das Ziel erhalten bleibt und die Rückkehr danach dorthin erfolgt; dieselbe Lage bei einer API-Anfrage ergibt 401 mit UNAUTHORIZED. Wer angemeldet ist, dessen Tarif die Seite aber nicht abdeckt, wird auf die Upgrade-Seite umgeleitet, mit der erforderlichen Stufe in der Abfragezeichenkette, und die entsprechende API-Anfrage ergibt 402 mit PAYMENT_REQUIRED nebst Feature-Schlüssel. Der Live-Chat ist genauso geschützt — auf der preview-Stufe zeigt die Support-Seite statt des Chats einen Upgrade-Aufruf. Ein vom Betrieb abgeschaltetes Feature antwortet mit 503, KILL_SWITCH und einem Retry-After-Header.

Gesperrt, gestutzt und verzögert — was kein Fehler ist

Zwei optische Zeichen bedeuten „im Tarif nicht enthalten“, und keines davon ist ein Fehler. Eine gesperrte Fläche liegt unter einer Schlossschicht, die sowohl Mausklicks als auch Tastaturaktivierung abfängt und den Upgrade-Dialog öffnet statt des darunterliegenden Links. Ein teilweise sichtbares Datenwidget bekommt stattdessen eine goldene Pille im Text — verwendet dort, wo Daten vorhanden, aber reduziert sind, etwa bei einem verzögerten Tick oder einer gestutzten Historientiefe. Zeigt ein Chart weniger Balken als erwartet und trägt diese Pille, wurde die Historie absichtlich gekürzt und ist nicht verloren.

Eine dritte Beobachtung erklärt sich über das Timing. Eine Zugriffsprüfung bleibt bewusst unbestimmt, bis die Berechtigungen geladen sind: Davor ist sie verborgen und wirkungslos, damit zahlende Nutzer nie einen kurz aufblitzenden Sperrzustand vor dem Freischalten sehen. Sichtbar ist das daran, dass eine geschützte Kachel direkt nach dem Laden einen Moment leer sein kann. Auf dem Server beantwortet dieselbe Regel API-Anfragen mit 402 und einer Nutzlast, die Feature-Schlüssel und erforderliche Stufe nennt, während eine Navigation im Browser auf die Upgrade-Seite umgeleitet wird, mit Quelle, ursprünglichem Pfad und erforderlicher Stufe in der Abfragezeichenkette — deshalb kann die Upgrade-Seite genau benennen, was geöffnet werden sollte.

Die Fehlercodes einer API-Antwort

Jede Antwort der App-eigenen API hat eine feste Form. Ein Erfolg trägt success: true, eine data-Nutzlast und einen Zeitstempel. Ein Fehlschlag trägt success: false und ein error-Objekt mit einem maschinenlesbaren code, einer lesbaren message und optional einem target, das das fehlerhafte Feld nennt, einem details-Objekt mit weiterem Zusammenhang und einer doc_url. Bei einer Meldung gehört der code dazu: Der Code ist stabil, der Wortlaut der Meldung nicht. Es gibt zwölf Codes, und jeder hängt an genau einem HTTP-Status.

Zwei Antwortformen liegen außerhalb dieses Satzes. Ältere Endpunkte antworten in einer alten Hülle aus code, msg, data und success, wobei code eine numerische Zeichenkette ist, nach Klassen gruppiert: 10xxx für Eingabeprobleme, 20xxx für Authentifizierung, 30xxx für Autorisierung, 40xxx für fehlende oder widersprüchliche Ressourcen, 50xxx für Serverfehler und 60xxx für vorgelagerte Dienste. Datenbankprobleme werden übersetzt, bevor sie ankommen: Eine verlorene Verbindung wird zu 503 mit „Database temporarily unavailable“, eine Abfrage über ihrer Zeitgrenze zu 504 mit „Request timed out“, ein Duplikat zu 409 und eine verletzte Bedingung zu 400. Die ersten beiden lohnen einen erneuten Versuch; die letzten beiden wiederholen sich, solange sich die Eingabe nicht ändert.

• BAD_REQUEST — 400. Die Anfrage war fehlerhaft aufgebaut. Die gesendeten Parameter prüfen.
• VALIDATION_ERROR — 400. Eine Eingabe hat die Prüfung nicht bestanden; die Antwort nennt sie in target.
• UNAUTHORIZED — 401. Keine gültige Sitzung. Anmelden und die Anfrage wiederholen.
• PAYMENT_REQUIRED — 402. Angemeldet, aber der Tarif deckt es nicht ab. details trägt featureKey, requiredTier und, bei Domain-Prüfungen, requiredDomain.
• FORBIDDEN — 403. Authentifiziert, aber nicht erlaubt. Der genaue Grund bleibt bewusst auf dem Server.
• NOT_FOUND — 404. Unter dieser Adresse gibt es keine solche Ressource.
• CONFLICT — 409. Die Ressource hat sich zwischenzeitlich geändert oder existiert bereits. Neu laden und erneut versuchen.
• PAYLOAD_TOO_LARGE — 413. Der Anfragerumpf überschreitet die zulässige Größe.
• RATE_LIMITED — 429. Zu viele Anfragen. Die Antwort trägt Retry-After, X-RateLimit-Limit und X-RateLimit-Remaining; KI-Endpunkte haben ein eigenes Budget und antworten mit dem eigenen Code AI_RATE_LIMITED.
• INTERNAL_ERROR — 500. Ein unerwarteter Serverfehler. Mit der Error ID melden.
• UPSTREAM_ERROR — 502. Ein Dienst, von dem der Endpunkt abhängt, ist ausgefallen. Später erneut versuchen.
• SERVICE_UNAVAILABLE — 503. Vorübergehend nicht verfügbar. Zu beachten: Ein absichtlich abgeschaltetes Feature nutzt einen anderen 503-Rumpf, weiter unten beschrieben.

kill switches: wer ein Feature abschaltet und für wie lange

Ein kill switch (Notausschalter) ist ein Ausschalter für ein einzelnes benanntes Feature, bedient vom Athenum-Team und nicht von der Nutzerseite, und er ist der Grund, warum eine Seite unerreichbar sein kann, während der Rest der App gesund ist. Zwei verschiedene Lagen erzeugen dasselbe 503. Ist das Feature abgeschaltet, weil sein Backend noch nicht ausgeliefert wurde, liest die Fehlerseite „Coming Soon“ und erklärt, dass das Feature in Entwicklung ist. Hat der Betrieb ein funktionierendes Feature abgeschaltet, liest die Seite „Temporarily Unavailable“. Beide Antworten weisen sich mit dem Code KILL_SWITCH und einem stabilen öffentlichen Feature-Namen wie funding-heatmap oder cme-detector aus.

Die Antwort sagt, wie lange zu warten ist. Jeder Schalter trägt seinen eigenen Retry-After-Wert: 60 Sekunden für die Funding Heatmap, 1800 Sekunden für den CME Detector und 300 Sekunden für alles ohne ausdrückliche Einstellung. API-Aufrufer erhalten dieselbe Information als application/problem+json, samt einer defaultKilled-Markierung, die den Fall „noch nicht gebaut“ vom Fall „vom Betrieb abgeschaltet“ trennt. Das 503 selbst wird nie zwischengespeichert, und erfolgreiche Antworten auf schaltbaren Endpunkten sind auf zehn Sekunden Zwischenspeicherung gedeckelt, ein Umlegen erreicht die Nutzerseite also schnell; ein gemeinsamer Zwischenspeicher kann die vorherige Antwort dennoch rund fünfzehn Sekunden nach dem Umlegen ausliefern.

Eine abgeschaltete Route ist normalerweise nicht anklickbar. Routen, die ein Schalter vollständig blockiert, werden aus den Karten der Startseite gefiltert und in der Befehlspalette verborgen — das 503 sehen also vor allem Personen mit einem Lesezeichen, einem Direktlink oder über die API. Nicht jeder Schalter blockiert eine Route: Manche ändern das Verhalten an Ort und Stelle, weshalb ein Feature betroffen sein kann, ohne dass irgendeine Seite 503 liefert. kill-switch-Seiten tragen keine Error ID, weil die Antwort eine bewusste Entscheidung und kein Vorfall ist und keine Kennung erfunden wird, um das Feld zu füllen.

Seitenweite Wartung gegenüber einem einzelnen ausgefallenen Feature

Ein geplantes Wartungsfenster sieht anders aus als jeder andere Fehler. Statt der üblichen Fehlerseite erscheint ein eigenständiges Dokument mit der Überschrift „We'll be back soon“, ohne Navigation, ohne Error ID und ohne Support-Link. Es wird mit HTTP 503 und einem Retry-After von einer Stunde ausgeliefert. Die Seite ist vollständig in sich geschlossen — Gestaltung und Logo sind eingebettet, und sie stellt keine Netzwerkanfragen —, sie wird also auch dann dargestellt, wenn Backend, Datenbank und Analytik gleichzeitig unerreichbar sind. Sie ist außerdem als nicht indexierbar markiert, damit Suchmaschinen den Ausfall als vorübergehend behandeln.

Die Sperre ist bewusst eng gefasst. Sie ersetzt nur Seitenanfragen des Browsers: GET- oder HEAD-Anfragen, die HTML verlangen. API-Aufrufe unter /api/ laufen direkt durch, ebenso die Gesundheitsendpunkte der Container und jede Anfrage nach Skripten, Stilen oder Schriften. Eine Folge davon ist gut zu kennen: Während der Wartung kann ein API-Client oder eine eingebettete Integration normal weiterarbeiten, während der Browser die Wartungsseite zeigt. Erscheint „We'll be back soon“, ist die ganze Seite betroffen; erscheint eine 503-Fehlerseite mit dem Namen eines Features, nur dieses Feature.

Ein leeres Feld lesen: Das Abzeichen benennt den Fehler

Felder auf den Macro-Seiten tragen ein kleines Abzeichen in der Ecke, und dieses Abzeichen ist der schnellste Weg, einen Ausfall von einer ruhigen Datenquelle zu unterscheiden. Fünf der Abzeichenzustände beschreiben echte Daten, zwei beschreiben das Feld selbst. Weil das Abzeichen aus denselben Aktualitätsregeln abgeleitet wird, nach denen das Feld zeichnet, kann es keinen Zustand behaupten, den die Daten nicht hergeben: Ein Feld ohne Inhalt wird nie mit STALE beschriftet, und ein fehlender Wert wird nie durch eine Ersatzzahl gefüllt.

Die Hüllen auf Feldebene liefern eine zweite Informationsschicht. Ein laufender erster Ladevorgang stellt ein Gerüst ohne Urteil und ohne Text dar. Ein im Transport gescheiterter Abruf zeigt eine Fehlerkarte mit dem Wortlaut „Fleet read failed — the source may still be live. Retry to reload.“ und eine Wiederholen-Schaltfläche — die Quelle kann durchaus gesund sein, und ein erneuter Versuch ist die richtige Antwort. Ein Abruf, der erfolgreich war, aber keine Zeilen lieferte, zeigt „Awaiting Fleet-Bridge“ mit dem UNAVAILABLE-Abzeichen. Die beiden sehen ähnlich aus und bedeuten Gegenteiliges: Das erste ist ein Verbindungsproblem, das sich wiederholen lässt, das zweite heißt, dass die Reihe noch nicht zu fließen begonnen hat.

TradeFI-Felder nennen den Grund in Worten statt über ein Abzeichen. Ist der Datenanbieter ausgefallen, meldet das Feld, dass die Daten vorübergehend nicht verfügbar sind. Hat der Anbieter mit nichts geantwortet, meldet es, dass für dieses Symbol keine Daten vorliegen. Der institutionelle Anteilsbesitz ergänzt einen dritten Fall: einen Hinweis, dass die Ansicht eine offizielle Teilmenge verfolgter Institutionen ist und repräsentativ statt vollständig — das ist eine Aussage über den Umfang, kein Fehler. Peer-Listen verhalten sich genauso und nennen eine vom Standard abweichende Quelle in einem Hinweis über dem Feld, wenn eine verwendet wurde.

• LIVE — eine untertägige oder Echtzeitbeobachtung innerhalb ihres erwarteten Takts.
• EOD — ein ehrlicher Periodenschluss für eine tägliche, wöchentliche, monatliche oder quartalsweise Reihe.
• STALE — ein echter Wert, aber älter als der erwartete Aktualisierungstakt der Reihe.
• FALLBACK — zuletzt als gut bekannte zwischengespeicherte Daten, ausdrücklich nicht der aktuelle Wert.
• MODEL — eine berechnete Heuristik oder eine Athenum-Konstruktion, keine direkte Beobachtung.
• UNAVAILABLE — das Feld ist in einem Fehlerzustand und es wird nichts dargestellt.
• LOADING — der erste Ladevorgang läuft noch und die Aktualität steht noch nicht fest.

Ein Problem melden: die Error ID

Scheitert eine Anfrage, zeigt die Fehlerseite den HTTP-Status, einen kurzen Titel und — sofern eine erzeugt wurde — eine Error ID. Diese Kennung wird für den konkreten Vorfall vergeben und an den aufgezeichneten Fehlerbericht gehängt, der Support findet damit genau diesen Fall. Am besten die Schaltfläche zum Kopieren daneben nutzen und dann „Chat with support“ wählen: Der Link trägt die Error ID bis zur Support-Seite weiter. Zur Meldung gehören die Error ID, die Seitenadresse und was gerade getan wurde. Nicht jeder Fehler hat eine — für ein vorübergehend abgeschaltetes Feature wird kein Platzhalter erfunden, das Feld fehlt dann schlicht.

Wohin die Error ID nach dem Kopieren geht

Die Kennung auf der Fehlerseite wird auf dem Server vergeben, einmal je Vorfall, in dem Moment, in dem der Fehler abgefangen wird. Der Server schreibt einen Protokolleintrag mit dieser Kennung sowie HTTP-Status, Fehlernamen, Anfragepfad, Anfragemethode und Zeitstempel; in der Produktion lässt der Eintrag bewusst Aufrufspuren und interne Einzelheiten weg. Dieselbe Kennung hängt am Vorfall, der an die Fehlerverfolgung geht, der Support kann die kopierte Kennung also dem aufgezeichneten Fehlschlag zuordnen. Anfragen, die schlicht auf eine fehlende Seite treffen, sind die Ausnahme: Sie erhalten zwar eine Kennung, werden aber nicht an die Fehlerverfolgung weitergereicht.

Was der Browser zurückbekommt, ist bewusst dünn — eine allgemeine Meldung plus die Kennung —, damit über die Seite keine internen Einzelheiten nach außen dringen. Ein Druck auf „Chat with support“ trägt die Kennung weiter: Der Link öffnet die Support-Seite mit einem Vorfallsthema, der Error ID und der Bitte, einen Chat zu öffnen, statt auf der fehlerhaften Seite ein Chat-Widget zu starten. Scheint die Kopieren-Schaltfläche nichts zu tun, wurde der Schreibzugriff auf die Zwischenablage verweigert — das passiert auf unsicheren Ursprüngen oder bei verweigerter Berechtigung — und der Fehlschlag wird in der Browserkonsole protokolliert; die Kennung ist dann von Hand zu markieren.

Ob der Live-Chat auf der Support-Seite tatsächlich verfügbar ist, hängt an drei Prüfungen vor dem Darstellen der Seite. Chat setzt einen bezahlten Tarif voraus: Auf der preview-Stufe zeigt die Seite an seiner Stelle einen Upgrade-Hinweis. Chat entfällt außerdem, solange der Schalter für den Support-Messenger aus ist, und solange die Anfrage eine Einwilligung braucht, die nicht erfasst ist — was für Anfragen gilt, die europäisch, britisch oder schweizerisch aussehen, und für Anfragen ganz ohne Landessignal, weil die Prüfung im Zweifel sperrt. In jedem dieser Fälle bietet die Seite weiterhin E-Mail und die Discord-Gemeinschaft an, und diese beiden sind unabhängig vom Tarif immer vorhanden.

Was vor einer Problemmeldung zu prüfen ist

Das meiste, wonach der Support fragen würde, steht bereits auf dem Bildschirm. Die folgenden Prüfungen dauern unter einer Minute und machen aus „es ist kaputt“ eine Meldung, mit der sich arbeiten lässt. Von außen nach innen vorgehen — ganze Seite, dann Seite, dann Feld —, weil jede Schicht einen anderen Zuständigen und eine andere Lösung hat. Nichts davon braucht Entwicklerwerkzeuge außer den zwei Punkten, die sie ausdrücklich nennen.

• Den Umfang bestimmen. Ist jede Seite betroffen, eine Seite oder ein Feld innerhalb einer ansonsten funktionierenden Seite? „We'll be back soon“ heißt die ganze Seite; eine 503-Seite, die ein Feature nennt, heißt nur dieses Feature.
• Den Wortlaut wörtlich lesen. „Coming Soon“ und „Temporarily Unavailable“ sind verschiedene Lagen, obwohl beide 503 sind, und die Feldtexte „Fleet read failed“ und „Awaiting Fleet-Bridge“ bedeuten Gegenteiliges.
• Nach einem Abzeichen sehen. LOADING, STALE, FALLBACK und UNAVAILABLE beschreiben jeweils eine andere Lage, und ein Schloss oder eine goldene Pille bedeutet eine Tarifgrenze und keinen Fehler.
• Nach einer Wartezeit einmal erneut versuchen. Vorübergehende Antworten nennen ihr eigenes Wartefenster im Retry-After-Header, sichtbar im Netzwerkbereich des Browsers; ein früherer Versuch liefert meist dieselbe Antwort.
• Bei einem leeren Chart die Browserkonsole öffnen und nach Zeilen mit dem Präfix [WebGLChart] suchen, dann prüfen, ob der Browser aktuell und die Hardwarebeschleunigung eingeschaltet ist.
• Die Error ID kopieren, falls eine angezeigt wird. Tut die Kopieren-Schaltfläche nichts, von Hand markieren — der Browser kann den Schreibzugriff auf die Zwischenablage verweigern.
• Seitenadresse, Uhrzeit und die unmittelbar vorangegangene Handlung notieren. Die Error ID benennt den Vorfall; diese drei benennen das eigentliche Ziel.

Fehlercodes der Collector

Der Futures-Datensammler versieht jeden Fehlschlag mit einem stabilen Code, und dieser Code erscheint in eckigen Klammern, wo immer der Fehlertext angezeigt oder protokolliert wird. Das sind Backend-Kennungen: Taucht eine in einer Support-Antwort oder einem Statushinweis auf, sagt sie, welche Stufe gescheitert ist und ob der Collector es wiederholt hat, auf eine andere Quelle ausgewichen ist oder aufgegeben hat.

Fehlercodes von Volume Delta

Der Volume-Delta-Endpunkt liefert einen Code mit dem Präfix VDLT_ und einen Hinweis. Wiederholbare Fehler sind vorübergehend — dieselbe Anfrage kann kurz darauf gelingen; bei den übrigen muss sich die Anfrage selbst ändern.

Weiterhin festgefahren

Der Support ist aus der App heraus erreichbar. Es gibt kein veröffentlichtes Dienstgüteziel, keine Verfügbarkeitszahl und keine zugesagte Antwortzeit, diese Seite nennt daher auch keine.