Token məlumatı tapılmır, null gəlir: 0, boş xana, yoxsa “yoxdur”?

Etherscan-in siyahı sorğularında status adlı xana var və sənəd onu belə izah edir: "1 if the request returned data, 0 otherwise. A status of 0 can indicate an error or a valid request that returned no records." Eyni “0” həm alınmayan sorğunu, həm də düzgün işləyib heç nə tapmayan sorğunu bildirə bilər; yalnız bu rəqəmi köçürən qeyd iki ayrı hadisəni bir xanaya sıxışdırır. Sıfır qeydli cavabda message və result sahələrinin əslində nə yazdığı hələ açıq sualdır.

Token araşdırmasında belə xanalar tez-tez çıxır və adətən üç variant qalır: 0, boş xana, ya da “yoxdur”. Üçü də tam doğru deyil və hər biri növbəti adamı başqa addıma aparır — cəmə qatmağa, yenidən yoxlamağa, ya da işi bağlamağa; ona görə əvvəlcə əldəki “boş”un formasına baxmaq lazımdır.

Bu mətndəki bütün ingiliscə sitatlar orijinaldır, izahlar isə bu mətnin öz ifadəsidir.

null, 0x və []: boş cavab hansı formalarda gəlir

2026-09-27 tarixində bir sorğu eyni Solana ictimai düyününə, təsadüfi yaradılmış və heç vaxt işlədilməmiş eyni açıq açarla iki sual verdi. getAccountInfo adi nəticə qaytardı: yanında düyünün həmin andakı slot-u, value isə null. Dərhal sonra eyni açar token kimi getTokenSupply ilə soruşuldu və nəticə gəlmədi, yalnız -32602 kodlu xəta obyekti: "Invalid param: could not find account". Eyni “yoxdur” bir dəfə nəticə qatında, zaman koordinatı ilə; ikinci dəfə xəta qatında, koordinatsız.

JSON-RPC 2.0 spesifikasiyası hər iki formanı götürür: cavabda ya nəticə, ya xəta olmalıdır ("Either the result member or error member MUST be included, but both members MUST NOT be included."), nəticənin dəyərini isə metodun özü müəyyən edir. Ona görə null-un mənası həmin metodun sənədində axtarılmalıdır.

Bütün nəticə null-dur

ethereum.org-un JSON-RPC sənədində blok üçün "A block object, or null when no block was found", qəbz üçün "A transaction receipt object, or null when no receipt was found" yazılıb. İcra qatı spesifikasiyası (ethereum/execution-apis) bu null-u "Not Found (null)" adlandırır və blok sorğularının nəticəsini notFound ilə Block arasında seçim kimi yazır. Solana-nın getAccountInfo metodunda da sorğulanan commitment-də hesab yoxdursa value null olur, sadəcə slot daşıyan bir qabığın içində.

Nəticə yoxdur, yalnız xəta obyekti var

Yuxarıdakı iki sorğu tək düyünün tək anlıq müşahidəsidir. Oxunan getTokenSupply sənədində mint olmayanda nə qaytarılacağı yazılmayıb, Solana xəta kodlarının toplu siyahısı isə bu mətn üçün tapılmadı. Xəta obyektində code və message olur, data isə əlavə edilə bilər. JSON-RPC xəta cədvəlində “məlumat yoxdur” sətri yoxdur: -32601 "Method not found" metodun yoxluğudur, -32000–-32099 arası tətbiqlərə saxlanılıb. “Hesab tapılmadı” mesajı cədvəldə "Invalid params" adlanan -32602 ilə gəlib.

Dəyər var, amma içi boşdur

eth_getCode-un nəticəsi spesifikasiyada onaltılıq bayt sətridir və 0x-dan sonra heç bir rəqəm olmamasına icazə verilir; spesifikasiyanın test nümunəsində mövcud olmayan hesab üçün gözlənilən cavab elə 0x-dır. ethereum.org-un metod izahı kodu olmayan ünvan üçün nə qaytarıldığını yazmır. 0x-ın “heç görünməmiş ünvan”, “adi xarici hesab” və “kodu silinmiş müqavilə” hallarını ayırıb-ayırmadığına dair bu dəfə mənbə tapılmadı, ona görə 0x bunların heç biri kimi oxunmamalıdır. Etherscan-də isə SourceCode müqavilə doğrulanmayanda boş olur — bu boşluq “doğrulanmayıb” deməkdir.

Boş massiv

2026-09-27 tarixində bir sorğu CoinGecko-nun açarsız bazar siyahısından mövcud olmayan koin identifikatorunu istədi və cavab mətni [] oldu; tək koinin təfərrüatı soruşulanda isə "coin not found" yazılmış xəta obyekti gəldi. Eyni “belə koin yoxdur”, iki uc nöqtədə iki forma. CoinGecko-nun xəta səhifəsindəki iki cədvəldə koinin olmaması üçün sətir yoxdur, ona görə hər iki forma yalnız həmin sorğunun müşahidəsidir.

Sahə ümumiyyətlə gəlmir

Solana-nın JSON strukturları sənədində “yoxdur”un iki yazılışı yanaşı durur: əməliyyatın meta sahəsi məlumat əlçatan olmayanda null olur, version isə versiya məlumatı olmayanda sadəcə buraxılır. Bir buraxılma da sorğunun özündən gəlir: bloklar accounts rejimində istənəndə innerInstructions, logMessages və başqa sahələr "intentionally omitted" olur. Sahənin görünməməsi sadəcə sorğu rejiminin dəyişməsi ola bilər.

Eyni null başqa sahədə başqa məna daşıyır

Formanı tanıdıqdan sonra onun hansı sahədə durduğuna baxmaq lazımdır. Eyni Solana sənədində hesab sorğusunun value = null olması hesabın olmadığını bildirir, əməliyyat statusunun err = null olması isə, sənədin sözü ilə, "null means the transaction succeeded". İki null, iki əks məna.

Ethereum əməliyyat obyektində də belədir: blockNumber üçün "null when its pending", to üçün "null when its a contract creation transaction" yazılıb (hər ikisində orijinal yazılış saxlanılıb). Heç birinin “tapılmadı” ilə əlaqəsi yoxdur.

Provayder spesifikasiyalarında null çox vaxt adi formadır. CoinGecko bazar siyahısı cavabında current_price, circulating_supply, max_supply və başqa sahələr həm required, həm nullable kimi işarələnib: açar mütləq gəlir, dəyər isə null ola bilər. Sahə izahları null-un səbəbini yazmır, ona görə səbəb uydurulmamalıdır. Bu spesifikasiya Pro versiyasınındır, pulsuz versiyanın sahə-sahə eyni olub-olmadığı növbəti yoxlamaya qalır. DEX Screener spesifikasiyası isə bütöv pairs massivini null ola bilən kimi işarələyir; 2026-09-27 tarixində hovuz olmayan bir ünvanla sorğuda pairs null gəldi, yanında spesifikasiyada təyin olunmamış pair sahəsi də vardı. Bu da olduğu kimi qeyd olunur.

Buna görə boş dəyəri köçürəndə üç şey birlikdə yazılır: hansı metod, hansı sahə, hansı forma. Girişdəki Etherscan statusu da bu qaydaya tabedir — status yanında message və result mətnləri saxlanmalıdır.

Spesifikasiya null, -32001 və 4444-ü üç ayrı “tapılmadı” kimi ayırır

“Hələ əldə edilməyib” ilə “qəti yoxdur” ayrı yazılmalıdır və bunun üçün spesifikasiya səviyyəsində hazır dayaq var.

İcra qatı spesifikasiyasındakı nisbətən yeni eth_getBlockAccessList metodunun izahı üç halı üç cavabla yazır: blok naməlumdursa və ya pending istənibsə nəticə null-dur; blok Amsterdam çəngəlindən əvvəldirsə, müştəri "-32001: Resource not found" qaytarmalıdır; blokun giriş siyahısı budanıbsa, "4444: Pruned history unavailable". Token araşdırması bu metodu işlətmir; o, üç halı yan-yana yazdığı üçün xatırlanır. Spesifikasiya eth_getBlockByNumber, eth_getBlockReceipts kimi blok sorğuları üçün də 4444-ü sadalayır; hansı müştəri və xidmətlərin bunu real qaytardığı və hansı versiyadan başladığı hələ təsdiqlənməyib.

Əks tərəfdən xəbərdarlıq EIP-4444-dən gəlir. Hələ qaralama (Draft) statusunda olan bu təklif müştərilərə köhnə blok başlıqlarını, gövdələrini və qəbzləri yerli budamağa icazə verir və açıq deyir ki, bəzi sorğular "won’t be able to tell whether a given hash is invalid or just outdated"; tətbiqlərin bunu necə idarə edəcəyi təklifin əhatəsindən kənardır. Bu, “Ethereum tarixi tam budayıb” demək deyil; amma düyünün null cavabı ən çoxu həmin düyünün həmin anda bu məlumata sahib olmadığını deyir.

HTTP qatı da oxşardır. RFC 9110-a görə 404 serverin hədəf resursun cari təqdimatını tapmadığını və ya onun varlığını açmaq istəmədiyini bildirir və yoxluğun müvəqqəti, yoxsa daimi olduğunu göstərmir; server qadağan olunmuş resursu “gizlətmək” üçün də 404 verə bilər. 410 ehtimal ki daimi yoxluqdur, amma server onu işlətməyə borclu deyil. Nəticədə boş dəyərlərin çoxu yalnız “bu mənbə, bu anda, vermədi” kimi yazıla bilər.

Bir çox “alınmadı” məlumatın özü ilə bağlı deyil: tarif planı, 429 və vaxt aşımı

Uğursuzluqları növlərə ayırmaq ona görə lazımdır ki, onların xeyli hissəsi tokeni yox, sorğu göndərənin vəziyyətini təsvir edir.

Kimlik və tarif planı

CoinGecko-nun 10005 kodu belə yazılıb: "Endpoint not available on your plan." Etherscan bəzi zəncirlər üçün "Free API access is not supported for this chain." yazır, test şəbəkəsində Pro uc nöqtəsinə müraciət də xəta verir. 2026-09-27 tarixində açarsız bir Etherscan sorğusu status "0" və result "Missing/Invalid API Key" qaytardı. Bunların hamısı yalnız “bu kimliklə alınmır” deməkdir.

Tezlik

CoinGecko-ya görə bütün sorğular dəqiqəlik limitə sayılır, "including 4xx and 5xx errors"; açarsız istifadə IP üzrə hesablanır və eyni IP-dəki istifadəçilər limiti bölüşür. Etherscan-də bir zəncirin ortaq pulsuz hovuzu bütün istifadəçiləri üzrə cəmlənir, ayrıca açara bağlı deyil. Solana-nın RPC icmalına görə ictimai uc nöqtələr limit aşılanda 429, trafik bloklananda 403 qaytara bilər. Konkret say və saniyələr dəyişdiyi üçün burada yazılmır — hər xidmətin limit səhifəsinə baxılmalıdır.

Server tərəfi

RFC 9110-a görə 503 müvəqqəti yüklənmə və ya texniki xidmət deməkdir, amma yüklənmiş server 503 əvəzinə bağlantını sadəcə rədd edə də bilər. 2026-09-27 tarixində eyni anda eyni sorğu paketi iki Ethereum ictimai düyününə göndərildi: biri adi cavab verdi, digəri üç sorğunun hamısına -32603 "Internal error" qaytardı. Bu tək müşahidə həmin düyünün işləmədiyini sübut etmir, yalnız göstərir ki, “bu dəfə alınmadı” ilə “zəncirdə yoxdur” arasında bir neçə qat var.

Həddən böyük sorğu

Etherscan vaxt aşımı xətasını xüsusilə böyük, vaxtında tamamlanmayan sorğu ilə izah edir və tarix və ya blok aralığını kiçiltməyi tövsiyə edir.

Bir sorğu üç qatda: observed, inferred, unresolved

observed, inferred və unresolved bu saytın tədqiqat qeydlərində işlətdiyi üç qatdır — müşahidə olunan, çıxarılan və həll olunmamış; bu, heç bir rəsmi sənədin təsnifatı deyil. Yuxarıdakı getAccountInfo sorğusunda üç qat belə yazılır:

• observed: hansı düyün, hansı commitment, cavabın öz slot-u, value = null. Bu qata yalnız cavabda birbaşa görünən şeylər düşür.
• inferred: həmin commitment və slot-da bu düyündə belə hesab yoxdur. Çıxarış hansı sahələrə söykəndiyini yazmalıdır — burada value və context.slot.
• unresolved: bu açıq açar zəncirdə heç vaxt görünməyibmi. Bir null cavabı buna cavab vermir; sual bu qatda qalır və çatışmayan sübut yazılır.

observed qatında commitment və slot-un yazılmasının səbəbi var: Solana sənədinə görə processed düyünün ən yeni görünüşünü verir və "it can still change if the cluster switches forks"; Ethereum sənədinə görə isə vəziyyət sorğusunda verilən blok parametri blokun hündürlüyünü müəyyən edir. Bunlar yazılmasa, təkrar yoxlamada eyni anın müqayisə olunub-olunmadığı bilinmir.

Üç qatdan əlavə bir qayda da var: uğursuzluğun özü də bir observed qeydidir. Nəticə alınmayan sorğunun vaxtı, mənbəyi, xəta forması və orijinal mətni uğurlu oxunuşlarla eyni səhifədə yazılır.

Yenidən yoxlama nöqtəsi: Retry-After və cavabın özü

Uğursuzluq qeydinin son xanası “növbəti dəfə haradan yoxlamalı” sualına cavabdır və çox vaxt cavab özü ipucu verir.

• Vaxt: RFC 9110-a görə 503-ə, RFC 6585-ə görə 429-a Retry-After əlavə oluna bilər; dəyəri HTTP tarixi və ya saniyədir. Xidmətlərin bunu real göndərib-göndərmədiyi heç bir xidmətdə yoxlanılmayıb — varsa köçürülür, yoxdursa “yoxdur” yazılır.
• Aralıq: vaxt aşımında yenidən yoxlama nöqtəsi daha kiçik blok və ya tarix aralığıdır.
• Nasazlıq: Etherscan status səhifəsinə görə result blok nömrəsidirsə, xidmət işləyir və açar etibarlıdır; xətadırsa, problem sorğuda və ya açardadır. Günlük icazə verilən və işlədilən çağırışlar limit bloku ilə nasazlığı ayırır.
• Mənbə: düyün və ya mənbə dəyişibsə, nəyin dəyişdiyi və yeni oxunuşun başqa yolla alındığı yazılır.
• Say: ən azı CoinGecko xətalı sorğuların da limitə sayıldığını açıq yazır, 429 cavabları isə RFC 6585-ə görə keşdə saxlanmamalıdır; son cəhdin vaxtı və cəhdlərin sayı yazılır.

Nəhayət, bəzi xanaların həmişəlik unresolved qalmasına icazə vermək lazımdır. Əldəki düyünlərin hamısı tarixi budayıbsa, EIP-4444 qaralaması özü etiraf edir ki, bəzi sorğular heşin etibarsız, yoxsa sadəcə köhnə olduğunu ayıra bilməyəcək; tarixi məlumatın müstəqil təşkilatlarca saxlanması və əlçatanlığının yoxlanmasını da öz əhatəsindən kənarda qoyur. Belə xanaya “hazırkı mənbələr cavab vermir” yazılır və sınanmış mənbələr əlavə olunur. Bu, 0, boş xana və ya “yoxdur”dan daha dürüstdür: növbəti oxucu biləcək ki, bu xana daha güclü təkrar cəhdi yox, yeni sübutu gözləyir.