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. 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. Tek bir üyeyle ilgili sorun kendi etiketini korur. 1232 baytı aşan bir üye, 1232 bayt sınırını 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.

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.

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. 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