Sorun giderme

Grafikler boş kalıyor ya da WebGL sorunu bildiriyor

Grafikler WebGL ile çizilir. Tarayıcı hiç WebGL bağlamı oluşturamıyorsa grafik başlatılamadığını bildirir ve tarayıcınızı güncellemenizi ya da donanım hızlandırmayı açmanızı ister — çözüm bu iki adımdır. Grafik bağlamı sonradan kaybolursa, örneğin bir GPU sıfırlamasından, atılan bir sekmeden ya da mobil bir cihazın uykudan dönmesinden sonra, grafik çizimin duraklatıldığını ve GPU toparlandığında devam edeceğini söyler. Kurtarma otomatiktir: tarayıcı bağlamı geri yüklediğinde grafik GPU kaynaklarını yeniden kurar ve mevcut mumları yeniden yükler, bu yüzden sayfayı yenilemek gerekmez. Yeniden kurulumun kendisi başarısız olursa grafik duraklatılmış kalır ve hata tarayıcı konsoluna yazılır.

Tarayıcınızın sağlaması gerekenler

Mum ve ısı haritası grafikleri bir WebGL2 bağlamında çizilir. Renderer tuvalden özellikle webgl2 ister ve tarayıcı hiçbir şey döndürmediğinde hata verir; grafiğin WebGL'in başlatılamadığını bildirip tarayıcıyı güncellemeyi ya da donanım hızlandırmayı açmayı önerdiği nokta burasıdır. Mumların kendisi için bir yazılımsal çizim yolu yoktur — açıklama katmanı düz bir 2D tuval kullanır, ancak WebGL2 olmadan fiyat serisi hiç çizilmez. Yalnızca ilk WebGL kuşağını destekleyen ya da hızlandırma kapalı çalışan bir tarayıcı bu nedenle tam olarak bu mesajla boş bir grafik üretir.

Bir bağlam oluşturulup sonradan kaybolduğunda — bir GPU sürücüsü sıfırlaması, atılan bir arka plan sekmesi, uykudan dönen bir mobil cihaz — grafik, tarayıcının kaybı varsayılan biçimde ele almasını iptal eder, ki otomatik geri yüklemeyi mümkün kılan şey budur, ve duraklatılmış duruma geçer. Geri yüklemede GPU kaynaklarını yeniden kurar, tampon sürümünü geçersiz kılarak her mumun yeniden yüklenmesini sağlar ve çizime döner. Her adım tarayıcı konsoluna [WebGLChart] önekli bir satır bırakır: biri kayıp için, biri başarılı yeniden kurulum için ve yeniden kurulum başarısız olursa bir hata satırı. Boş bir grafiğe dair bir bildirime eklenecek en hızlı kanıt bu üç satırdır.

Giriş yönlendirmeleri, yükseltme uyarıları ve kapatılmış özellikler

Oturumunuz kapalıyken korumalı bir sayfayı açmak sizi hedefiniz korunarak giriş sayfasına gönderir ve sonrasında oraya geri döndürür; aynı durum bir API isteğinde UNAUTHORIZED ile 401 yanıtı verir. Giriş yapmışsanız ama planınız sayfayı kapsamıyorsa, sorgu dizesinde gereken kademeyle upgrade sayfasına yönlendirilirsiniz ve eşdeğer API isteği özellik anahtarıyla birlikte PAYMENT_REQUIRED ile 402 yanıtı verir. Canlı sohbet de aynı şekilde kapıya bağlıdır — preview kademesinde destek sayfası sohbet yerine bir yükseltme çağrısı gösterir. Bir operatör tarafından kapatılmış bir özellik, KILL_SWITCH ve bir Retry-After başlığıyla 503 yanıtı verir.

Kilitli, kısıtlı ve gecikmeli — neler arıza değildir

İki görsel işaret "planınız bunu içermiyor" anlamına gelir ve hiçbiri hata değildir. Kapıya bağlı bir yüzey, hem fare tıklamalarını hem de klavyeyle etkinleştirmeyi yakalayan ve alttaki bağlantı yerine yükseltme penceresini açan bir asma kilit katmanıyla örtülür. Kısmen görünen bir veri widget'ı ise bunun yerine satır içi altın renkli bir etiket alır — verinin mevcut ama azaltılmış olduğu yerlerde kullanılır, örneğin gecikmeli bir fiyat ya da kısıtlanmış bir geçmiş derinliği. Bir grafik beklediğinizden az çubuk gösteriyorsa ve bu etiketi taşıyorsa, geçmiş kaybolmamış, bilerek kısaltılmıştır.

Üçüncü bir gözlemi zamanlama açıklar. Bir kapı, yetkileriniz yüklenene kadar bilinçli olarak belirsiz kalır: o ana kadar gizli ve işlevsizdir, böylece ödeme yapan kullanıcılar kilit açılmadan önce bir kilitli durum parıltısı görmez. Görünür sonucu şudur: kapıya bağlı bir kutucuk, sayfa yüklendikten hemen sonra bir an boş kalabilir. Sunucuda ise aynı politika API isteklerine 402 ve özellik anahtarıyla gereken kademeyi adlandıran bir gövdeyle yanıt verirken, tarayıcı gezinmesini kaynağı, özgün yolu ve gereken kademeyi sorgu dizesinde taşıyarak upgrade sayfasına yönlendirir — upgrade sayfasının size tam olarak neyi açmaya çalıştığınızı söyleyebilmesinin nedeni budur.

Bir API yanıtının taşıdığı hata kodları

Uygulamanın kendi API'sinden gelen her yanıtın sabit bir biçimi vardır. Başarı; success: true, bir data yükü ve bir zaman damgası taşır. Hata ise success: false ve makine okunur bir code, insan tarafından okunabilir bir message, ayrıca isteğe bağlı olarak hatalı alanı adlandıran bir target, ek bağlam içeren bir details nesnesi ve bir doc_url tutan bir error nesnesi taşır. Bir sorunu bildirirken code değerini yazın: kod kalıcıdır, mesajın ifadesi değildir. On iki kod vardır ve her biri tek bir HTTP durumuna bağlıdır.

İki yanıt biçimi bu kümenin dışında kalır. Eski uç noktalar code, msg, data ve success içeren eski bir zarfla yanıt verir; burada code, sınıflara göre gruplanmış sayısal bir metindir: girdi sorunları için 10xxx, kimlik doğrulama için 20xxx, yetkilendirme için 30xxx, eksik ya da çakışan kaynaklar için 40xxx, sunucu hataları için 50xxx ve kaynak hizmetler için 60xxx. Veritabanı sorunları size ulaşmadan önce çevrilir: kopan bir bağlantı "Database temporarily unavailable" ile 503'e, zaman sınırını aşan bir sorgu "Request timed out" ile 504'e, bir yineleme 409'a ve bir kısıt ihlali 400'e dönüşür. İlk ikisini yeniden denemeye değer; son ikisi ise girdi değişene kadar tekrarlanır.

• BAD_REQUEST — 400. İstek hatalı biçimlendirilmiş. Gönderdiğiniz parametreleri kontrol edin.
• VALIDATION_ERROR — 400. Bir girdi doğrulamadan geçemedi; yanıt bunu target alanında adlandırır.
• UNAUTHORIZED — 401. Geçerli oturum yok. Giriş yapın ve isteği tekrarlayın.
• PAYMENT_REQUIRED — 402. Giriş yapılmış, ancak plan bunu kapsamıyor. details alanı featureKey, requiredTier ve alan kapıları için requiredDomain taşır.
• FORBIDDEN — 403. Kimlik doğrulanmış ama izin yok. Kesin neden bilinçli olarak sunucu tarafında tutulur.
• NOT_FOUND — 404. O adreste böyle bir kaynak yok.
• CONFLICT — 409. Kaynak siz çalışırken değişti ya da zaten var. Sayfayı yenileyip tekrar deneyin.
• PAYLOAD_TOO_LARGE — 413. İstek gövdesi kabul edilen boyutu aşıyor.
• RATE_LIMITED — 429. Çok fazla istek. Yanıt Retry-After, X-RateLimit-Limit ve X-RateLimit-Remaining taşır; yapay zekâ uç noktalarının kendi ayrı bütçesi vardır ve ayrı AI_RATE_LIMITED koduyla yanıt verirler.
• INTERNAL_ERROR — 500. Beklenmeyen bir sunucu hatası. Error ID ile birlikte bildirin.
• UPSTREAM_ERROR — 502. Uç noktanın bağlı olduğu bir hizmet başarısız oldu. Daha sonra tekrar deneyin.
• SERVICE_UNAVAILABLE — 503. Geçici olarak kullanılamıyor. Bilerek kapatılmış bir özelliğin farklı bir 503 gövdesi kullandığını unutmayın; aşağıda anlatılıyor.

Kill switch: bir özelliği kim kapatır ve ne kadar süreyle

Kill switch, adı belirli tek bir özelliğin kapatma anahtarıdır; sizin değil Athenum ekibinin kullandığı bu anahtar, uygulamanın geri kalanı sağlıklıyken bir sayfaya ulaşılamamasının nedenidir. İki farklı durum aynı 503'ü üretir. Özellik, arka ucu henüz yayına alınmadığı için kapalıysa hata sayfasında "Coming Soon" yazar ve özelliğin geliştirme aşamasında olduğu açıklanır. Bir operatör çalışan bir özelliği kapattıysa sayfada "Temporarily Unavailable" yazar. Her iki yanıt da kendini KILL_SWITCH kodu ve funding-heatmap ya da cme-detector gibi kalıcı bir genel özellik adıyla tanıtır.

Yanıt, ne kadar beklemeniz gerektiğini de söyler. Her anahtarın kendi Retry-After değeri vardır: funding ısı haritası için 60 saniye, CME Detector için 1800 saniye ve açık bir ayarı olmayan her şey için 300 saniye. API çağıranlar aynı bilgiyi application/problem+json olarak alır; buna, yayına alınmamış durumu operatör durumundan ayıran bir defaultKilled bayrağı da dâhildir. 503'ün kendisi asla önbelleklenmez ve anahtarlanabilir uç noktalardaki başarılı yanıtlar en fazla on saniye önbelleklenir; böylece bir anahtar değişikliği size hızla ulaşır, yine de paylaşılan bir önbellek değişiklikten sonra yaklaşık on beş saniye boyunca önceki yanıtı sunabilir.

Kapatılmış bir rotaya normalde tıklayarak ulaşılamaz. Bir anahtarın tümüyle engellediği rotalar ana sayfa kartlarından ayıklanır ve komut paletinden gizlenir; bu yüzden 503'ü çoğunlukla yer imi, doğrudan bağlantı ya da API kullananlar görür. Her anahtar bir rotayı engellemez: bazıları bunun yerine davranışı yerinde değiştirir, bu yüzden hiçbir sayfa 503 döndürmeden de bir özellik etkilenebilir. Kill switch sayfaları Error ID taşımaz, çünkü yanıt bir olay değil bilinçli bir karardır ve alanı doldurmak için tanımlayıcı uydurulmaz.

Site geneli bakım ile tek bir özelliğin arızası

Planlı bir bakım penceresi diğer tüm hatalardan farklı görünür. Olağan hata sayfası yerine, gezinmesi, Error ID'si ve destek bağlantısı olmayan, "We'll be back soon" başlıklı bağımsız bir belge görürsünüz. HTTP 503 ve bir saatlik bir Retry-After ile sunulur. Sayfa tamamen kendi kendine yeter — stilleri ve logosu gömülüdür ve hiçbir ağ çağrısı yapmaz — bu yüzden arka uç, veritabanı ve analitik tamamen erişilemez olsa bile görüntülenir. Ayrıca dizine eklenmez olarak işaretlenir, böylece arama motorları kesintiyi geçici sayar.

Bu kapı bilinçli olarak dardır. Yalnızca tarayıcı sayfa isteklerinin yerine geçer: HTML isteyen GET veya HEAD istekleri. /api/ altındaki API çağrıları, konteyner sağlık uç noktaları ve betik, stil ya da yazı tipi istekleri doğrudan geçer. Bilinmesi gereken bir sonuç: bakım sırasında bir API istemcisi ya da gömülü bir entegrasyon normal çalışmaya devam ederken tarayıcı bakım sayfasını gösterebilir. "We'll be back soon" görüyorsanız tüm site etkilenmiştir; tek bir özelliği adlandıran bir 503 hata sayfası görüyorsanız yalnızca o özellik etkilenmiştir.

Boş bir paneli okumak: rozet hatayı adlandırır

Makro sayfalarındaki paneller köşede küçük bir rozet taşır ve bu rozet, bir kesintiyi sessiz bir veri kaynağından ayırmanın en hızlı yoludur. Rozet durumlarının beşi gerçek veriyi, ikisi panelin kendisini anlatır. Rozet, panelin çizim için kullandığı aynı tazelik kurallarından türetildiği için verinin desteklemediği bir durumu iddia edemez: gösterecek hiçbir şeyi olmayan bir panel asla STALE olarak etiketlenmez ve eksik bir değerin yerine asla vekil bir sayı konmaz.

Panel düzeyindeki kabuklar ikinci bir bilgi katmanı ekler. Devam eden ilk yükleme, hiçbir hüküm ve metin içermeyen bir iskelet gösterir. Aktarımda başarısız olan bir okuma, "Fleet read failed — the source may still be live. Retry to reload." ifadesiyle bir hata kartı ve bir yeniden deneme düğmesi gösterir — kaynak pekâlâ sağlıklı olabilir ve doğru tepki yeniden denemektir. Başarılı olan ama hiç satır döndürmeyen bir okuma, UNAVAILABLE rozetiyle "Awaiting Fleet-Bridge" gösterir. Bu ikisi benzer görünür ama zıt anlamlara gelir: birincisi yeniden deneyebileceğiniz bir bağlantı sorunudur, ikincisi serinin henüz akmaya başlamadığı anlamına gelir.

TradeFI panelleri nedeni rozet yerine kelimelerle bildirir. Veri sağlayıcı başarısız olduğunda panel, verinin geçici olarak kullanılamadığını söyler. Sağlayıcı boş yanıt verdiğinde ise o sembol için veri bulunmadığını söyler. Kurumsal sahiplik üçüncü bir durum ekler: görünümün resmî olarak takip edilen kurumların bir alt kümesi olduğunu ve kapsayıcı değil temsilî olduğunu açıklayan bir not — bu bir arıza değil, kapsam beyanıdır. Emsal listeleri de aynı şekilde davranır ve varsayılan olmayan bir kaynak kullanıldığında bunu panelin üstündeki bir notta adlandırır.

• LIVE — beklenen sıklığı içinde, gün içi ya da gerçek zamanlı bir gözlem.
• EOD — günlük, haftalık, aylık veya üç aylık bir seri için dürüst bir dönem kapanışı.
• STALE — gerçek bir değer, ancak serinin beklenen güncelleme sıklığından daha eski.
• FALLBACK — bilinen son geçerli önbellek verisi, açıkça güncel değer değil.
• MODEL — hesaplanmış bir sezgisel değer ya da Athenum kurgusu, doğrudan bir gözlem değil.
• UNAVAILABLE — panel hata durumunda ve hiçbir şey çizilmiyor.
• LOADING — ilk yükleme hâlâ sürüyor ve tazelik henüz belirlenmedi.

Bir sorunu bildirmek: Error ID'niz

Bir istek başarısız olduğunda hata sayfası HTTP durumunu, kısa bir başlığı ve — üretildiyse — bir Error ID gösterir. Bu tanımlayıcı sizin özel olayınız için üretilir ve kaydedilen hata raporuna eklenir, böylece destek tam olarak sizin durumunuzu bulabilir. Yanındaki Kopyala düğmesini kullanın, ardından “Destekle sohbet et” seçeneğini seçin: bağlantı Error ID'yi destek sayfasına taşır. Bildirirken Error ID'yi, sayfa adresini ve ne yaptığınızı ekleyin. Her hatada bir Error ID olmaz — geçici olarak kapatılmış bir özellik için yer tutucu uydurulmaz, bu yüzden alan yalnızca boş kalır.

Error ID'niz kopyaladıktan sonra nereye gider

Hata sayfasındaki tanımlayıcı, hata yakalandığı anda sunucuda ve olay başına bir kez üretilir. Sunucu, bu tanımlayıcıyı HTTP durumu, hata adı, istek yolu, istek yöntemi ve bir zaman damgasıyla birlikte bir günlük kaydına yazar; üretimde bu kayıt yığın izlerini ve iç ayrıntıları bilinçli olarak dışarıda bırakır. Aynı tanımlayıcı hata izleme sistemine gönderilen olaya da eklenir, böylece destek sizdeki kimliği kaydedilen hatayla eşleştirebilir. Yalnızca var olmayan bir sayfaya giden istekler istisnadır: onlar da bir tanımlayıcı alır, ancak hata izlemeye iletilmezler.

Tarayıcının geri aldığı bilgi bilinçli olarak incedir — genel bir mesaj ve tanımlayıcı — böylece sayfadan hiçbir iç ayrıntı sızmaz. "Destekle sohbet et" düğmesine basmak tanımlayıcıyı ileri taşır: bağlantı, hata veren sayfada bir sohbet penceresi açmak yerine destek sayfasını bir olay konusu, Error ID ve sohbet açma isteğiyle açar. Kopyala düğmesi hiçbir şey yapmıyor gibi görünüyorsa panoya yazma reddedilmiştir — bu, güvenli olmayan kaynaklarda ya da pano izni verilmediğinde olur — ve hata tarayıcı konsoluna kaydedilir; bu durumda tanımlayıcıyı elle seçin.

Destek sayfasında canlı sohbetin gerçekten kullanılabilir olup olmadığı, sayfa görüntülenmeden önce yapılan üç kontrole bağlıdır. Sohbet ücretli bir plan ister: preview kademesinde sayfa bunun yerine bir yükseltme uyarısı gösterir. Sohbet ayrıca destek mesajlaşma anahtarı kapalıyken ve istek, kaydedilmemiş bir onay gerektirdiğinde de verilmez — Avrupa, Britanya ya da İsviçre kaynaklı görünen istekler ile hiçbir ülke sinyali taşımayan istekler için durum budur, çünkü kontrol güvenli tarafta kapalı kalır. Bu durumların hepsinde sayfa yine e-posta ve Discord topluluğunu sunar; bu ikisi plandan bağımsız olarak her zaman bulunur.

Bir sorunu bildirmeden önce neleri kontrol etmelisiniz

Desteğin size soracağı şeylerin çoğu zaten ekranda görünür. Aşağıdaki kontroller bir dakikadan kısa sürer ve "bozuk" ifadesini üzerine iş yapılabilecek bir bildirime çevirir. Dıştan içe doğru ilerleyin — önce tüm site, sonra sayfa, sonra panel — çünkü her katmanın sahibi ve çözümü farklıdır. Açıkça belirtilen iki madde dışında burada hiçbir şey geliştirici araçları gerektirmez.

• Kapsamı belirleyin. Her sayfa mı etkilendi, tek bir sayfa mı, yoksa aksi hâlde çalışan bir sayfadaki tek bir panel mi? "We'll be back soon" tüm site demektir; bir özelliği adlandıran 503 sayfası yalnızca o özellik demektir.
• İfadeyi birebir okuyun. "Coming Soon" ile "Temporarily Unavailable" ikisi de 503 olsa bile farklı durumlardır ve "Fleet read failed" ile "Awaiting Fleet-Bridge" panel metinleri zıt anlamlara gelir.
• Bir rozet arayın. LOADING, STALE, FALLBACK ve UNAVAILABLE her biri farklı bir durumu anlatır; asma kilit ya da altın etiket ise arıza değil, plan sınırı demektir.
• Bekledikten sonra bir kez yeniden deneyin. Geçici yanıtlar kendi yeniden deneme penceresini Retry-After başlığında belirtir; bu başlık tarayıcının ağ panelinde görünür. Daha erken denemek genellikle aynı yanıtı döndürür.
• Boş bir grafik için tarayıcı konsolunu açıp [WebGLChart] önekli satırları arayın, ardından tarayıcının güncel ve donanım hızlandırmanın açık olduğunu doğrulayın.
• Gösteriliyorsa Error ID'yi kopyalayın. Kopyala düğmesi bir şey yapmıyorsa elle seçin — panoya yazma tarayıcı tarafından reddedilebilir.
• Sayfa adresini, saati ve hatadan hemen önce ne yaptığınızı not edin. Error ID olayı tanımlar; bu üçü ise neyi başarmaya çalıştığınızı tanımlar.

Toplayıcı hata kodları

Futures veri toplayıcısı her hatayı kalıcı bir kodla etiketler ve bu kod, hata metninin gösterildiği ya da kaydedildiği her yerde köşeli parantez içinde görünür. Bunlar arka uç tanımlayıcılarıdır: bir destek yanıtında ya da bir durum notunda birini görmek, hangi aşamanın başarısız olduğunu ve toplayıcının yeniden mi denediğini, başka bir kaynağa mı geçtiğini yoksa pes mi ettiğini söyler.

Volume Delta hata kodları

Volume Delta uç noktası VDLT_ önekli bir kod ve bir ipucu döndürür. Yeniden denenebilir hatalar geçicidir — aynı istek kısa süre sonra başarılı olabilir; diğerleri için isteğin kendisinin değişmesi gerekir.

Hâlâ takıldıysanız

Uygulama içinden destek ile iletişime geçin. Yayımlanmış bir hizmet seviyesi hedefi, çalışma süresi oranı ya da garanti edilen yanıt süresi yoktur, bu yüzden bu sayfa da böyle bir şey belirtmez.