Skip to main content

Kabul Edilmiş Olması Bloğa Girdiği Anlamına Gelmez

Başarılı bir yanıt, Apex uç noktasının işleminizi elinde tuttuğu ve onu bloğa girene veya blockhash’inin süresi dolana kadar liderlere yarıştırdığı anlamına gelir. İşlemin bloğa girdiği anlamına gelmez. Her gönderimi bir Solana RPC üzerinde getSignatureStatuses ile onaylayın. En iyi uygulamalar sayfasına bakın.

Kabul Edilen Bir İşlem Neden Bloğa Girmedi

Panelinizde kabul edilen her işlemin nasıl sonuçlandığı kaydedilir. İşlem bloğa girmediyse aşağıdaki kodlardan biri nedenini söyler: Bloğa girip zincir üzerinde başarısız olan bir işlem başarısız olarak görünür: talimatları bir hata döndürdüğü için bahşiş hiç ödenmedi. Apex bir işlemi şu sırayla kontrol eder: API anahtarı, hız sınırı, işlemin geçerliliği ve boyutu, ardından bahşiş. Hatayı ilk başarısız olan kontrol belirler. Her kontrol geçilene kadar hiçbir yere hiçbir şey gönderilmez, dolayısıyla reddedilen bir işlemin maliyeti yoktur.

JSON-RPC Hataları

Düz HTTP Hataları

/send ve /send-bin üzerinde başarı, {"signature": "..."} içeren HTTP 200 yanıtıdır. /send-batch, {"attempted": n, "accepted": n, "rejected": n, "results": [...]} ile 200 yanıtı verir; buradaki her sonuç, çerçeve sırasına göre, ya {"signature": "..."} ya da {"error": "<label>", "message": "..."} olur. /send-bundle, {"bundle_id": "...", "signatures": ["...", "..."]} ile 200 yanıtı verir. Hatalar, makine tarafından okunabilir bir etiket ve insan tarafından okunabilir bir mesaj içeren JSON’dur:
Önce HTTP durumuna göre dallanın. Sözleşmenin kararlı kısmı odur. 400 altında tanımadığınız bir etiketi “işlemi düzeltin” olarak değerlendirin.
/send-batch, isteğin kendisi düzgün biçimlendirilmiş olduğu sürece 200 yanıtı verir ve her çerçeveyi results içinde ayrı ayrı bildirir. Yalnızca durum koduna değil, rejected alanına ve her kayda bakın. POST /send-batch bölümüne bakın. bundle etiketi (HTTP 400), bir paketin bütün olarak reddedildiği anlamına gelir: 4’ten fazla üye, yinelenen bir üye, bu anahtar veya uç nokta için paketlerin kullanılamaması ya da blok motorunun paketi reddetmesi. Blok motoru reddettiğinde, Apex nedeni tanıyorsa (bir üye zaten işlenmiş, blockhash süresi dolmuş veya bilinmiyor, blok motoru bir üyeyi zaten görmüş) mesaj nedeni söyler, tanımıyorsa “the block engine rejected the bundle” olur; aynı paketi yeniden göndermek yine başarısız olur. Tek bir üyeyle ilgili sorun kendi etiketini korur. Boyut sınırını (v1 için 4096 bayt, legacy veya v0 için 1232) aşan bir üye, sınırı belirten bir mesajla malformed olarak döner; bahşişli iki üye multiple_tips, bahşişli hiç üye olmaması ise no_tip olarak döner. Uç noktanın şu anda blok motoruna iletemediği bir paket busy (HTTP 503, JSON-RPC -32603) yanıtı alır: uç noktanın o saniyeki blok motoru hakkı dolmuştur, blok motoru uç noktayı hız sınırına takmıştır ya da yanıt vermemiştir. Hiçbir şey gönderilmemiştir; kısa bir süre sonra yeniden deneyin ya da işlemleri tek tek gönderin. nonce_used etiketi (HTTP 400, JSON-RPC -32602), uç noktanın değiştirildiğini zaten gördüğü bir nonce değerine karşı imzalanmış durable nonce işlemini reddeder: o nonce’u başka bir işlem kullandı, bu yüzden bu işlem asla bloğa giremez. Hiçbir şey gönderilmez. Uç noktanın görmediği bir değer her zamanki gibi kabul edilir.

Ayrıntılı Bahşiş Hataları

QUIC Kabul Kodları

Çift yönlü bir QUIC akışı tek bir kabul koduyla yanıt verir. Tek yönlü bir akış hiçbir şey döndürmez, bu yüzden entegrasyon sırasında çift yönlü bir akış kullanın. QUIC el sıkışmasının kendisi reddedilirse bağlantı, uygulama hatası 1 (istemci sertifikası yok), 2 (bilinmeyen anahtar) veya 3 (çok fazla bağlantı) ile kapanır. Kimlik doğrulama sayfasına bakın. Rust istemcisinde send_transaction_with_response bir reddi Error::Rejected { code, message } hatasına dönüştürür ve 4096 baytı aşan bir işlem, herhangi bir şey gönderilmeden önce yerel olarak Error::TooLarge ile başarısız olur. Go istemcisinde SendTransactionWithResponse, aynı Code ve Message değerlerine sahip bir *apex.RejectedError döndürür ve boyutu aşan bir işlem yerel olarak *apex.TooLargeError ile başarısız olur.

Hangi Hatalar Yeniden Denenmeli

Kabul edilmiş bir işlemi yeniden göndermeniz gerekmez. Apex onu zaten bloğa girene veya blockhash’in süresi dolana kadar yeniden dener. O zamana kadar bloğa girmediyse onu yeni bir blockhash ile yeniden oluşturun ve yeni işlemi gönderin.

Hız Sınırları

Hız sınırları API anahtarı başınadır ve anahtarın katmanı tarafından belirlenir. Sınır, tüm taşıma yöntemleri genelinde saniye başına işlemleri sayar: JSON-RPC, HTTP rotaları ve QUIC aynı kotadan yer ve toplu gönderimin her çerçevesi bir işlem olarak sayılır. Standart katman saniyede 5 işleme izin verir ve ani artış payı yoktur: aynı anda en fazla 5. Pro katmanı saniyede 50 işleme ve bunun üzerine aynı anda 10 işlem daha izin verir. Hesabınız için kararlaştırılan bir sınır katmanın hızının yerine geçer, ani artış payı aynı kalır. Sınırı aştığınızda -32029, HTTP 429 veya kabul kodu 2 alırsınız. Reddedilen işlem kuyruğa alınmaz, bu yüzden hâlâ önemliyse bir süre sonra yeniden gönderin. Katmanınızın sınırı ve bahşiş tabanı, OrbitFlare gösterge panelinde Dashboard > Apex altında anahtarın yanında gösterilir. Bunları yükseltmek için Discord üzerinden ekiple iletişime geçin.

Bir Bakışta Sınırlar