เอเจนต์ของคุณเรียกใช้ API. API ส่งคืนสถานะ 429. เอเจนต์ของคุณพยายามเรียกซ้ำทันที ได้รับ 429 อีกครั้ง พยายามซ้ำอีกครั้ง และตอนนี้คุณก็มีวงจรที่ส่งคำขอจำนวนมากไปยังบริการที่ถูกจำกัดความเร็ว จนกว่าการทำงานจะหยุดลงหรือค่าใช้จ่ายพุ่งสูงขึ้น. ไม่มีใครเขียนวงจรนั้นโดยตั้งใจ. มันเกิดจากเวอร์ชันที่ซื่อตรงของ "การจัดการข้อผิดพลาด" และเป็นสิ่งเดียวที่พบบ่อยที่สุดที่นักพัฒนาสอบถามใน กระดานสนทนา Anthropic SDK.
การกู้คืนข้อผิดพลาดเป็นส่วนหนึ่งของการสร้างเอเจนต์ที่แยกแยะการสาธิตที่สะอาดจากการที่คุณต้องแจ้งเตือนผู้อื่น. โมเดลไม่ใช่ปัญหา. ปัญหาคือสิ่งที่โค้ดของคุณทำเมื่อการเรียกใช้เครื่องมือตอบสนองช้า ถูกจำกัดความเร็ว หรือเสีย. หากกู้คืนได้ถูกต้อง การพึ่งพาที่ไม่เสถียรก็กลายเป็นเพียงการหยุดชั่วคราวสั้นๆ ที่ผู้ใช้ไม่เคยสังเกตเห็น. หากทำผิดพลาด สถานะ 500 เพียงครั้งเดียวก็อาจกลายเป็นเหตุการณ์ร้ายแรง. คู่มือนี้ครอบคลุมสี่รูปแบบหลักที่รับภาระส่วนใหญ่: การลองใหม่พร้อม Backoff, การตั้งเวลาหมดอายุ, Circuit Breakers และ Idempotency Keys. จากนั้นจะแสดงวิธีทดสอบสิ่งเหล่านี้กับ Mock ก่อนที่ผู้ใช้จะพบช่องโหว่ให้คุณ. สำหรับภาพรวมที่กว้างขึ้นว่าเอเจนต์ AI ล้มเหลวได้อย่างไร ให้เริ่มต้นด้วย สาเหตุที่เอเจนต์ AI พังในการใช้งานจริง.
คุณไม่สามารถทดสอบการกู้คืนกับ API ที่ทำงานปกติได้
นี่คือกับดัก. การพึ่งพาของคุณทำงานได้ดีในการพัฒนา. คุณเขียนเอเจนต์ของคุณ การเรียกใช้งานสำเร็จ การสาธิตดูสะอาดตา และคุณก็ปล่อยออกสู่ตลาด. โค้ดการกู้คืนไม่เคยทำงานเลยแม้แต่ครั้งเดียว เพราะ API ที่ทำงานปกตินั้นไม่เคยส่งคืนข้อผิดพลาดที่ควรจะจัดการ. ครั้งแรกที่ตรรกะ Backoff ของคุณทำงานคือในการใช้งานจริง ซึ่งเป็นการรับมือกับการหยุดทำงานจริง โดยมีผู้ใช้จริงกำลังเฝ้าดู. นั่นคือสถานที่ที่แย่ที่สุดในการค้นหาข้อผิดพลาดจากการพิมพ์ในวงจรการลองใหม่.
ดังนั้นกฎจึงง่าย. ในการทดสอบการกู้คืน คุณต้องสร้างความล้มเหลวขึ้นมาโดยเจตนา. สร้าง Mock ของ API ที่เอเจนต์เรียกใช้ ตั้งโปรแกรมให้ส่งคืนสถานะ 429, 500, การหมดเวลา หรือ Body ที่ผิดรูปแบบ ชี้เอเจนต์ไปที่ Mock นั้น และดูว่ามันทำอะไร. ความล้มเหลวกลายเป็นสิ่งที่คุณกระตุ้นในการทดสอบ แทนที่จะเป็นสิ่งที่กระตุ้นให้คุณต้องตื่นมาตอนตี 3. Apidog สร้าง Mock นั้นและเขียนสคริปต์การตอบสนอง ซึ่งจะดำเนินการผ่านส่วนการทดสอบในตอนท้าย.
การลองใหม่ด้วย Exponential Backoff และ Jitter
การลองใหม่คือแนวป้องกันแรก และเวอร์ชันที่ซื่อตรงคือกกับดัก. ดักจับข้อผิดพลาด แล้วเรียกซ้ำทันที. สำหรับข้อผิดพลาดชั่วคราว การทำแบบนั้นได้ผล. แต่สำหรับบริการที่อยู่ภายใต้ภาระหนัก มันกลับทำให้สถานการณ์แย่ลง เพราะไคลเอ็นต์ที่ล้มเหลวทุกตัวจะลองใหม่พร้อมกัน และการรุมเร้าดังกล่าวจะทำให้บริการหยุดทำงาน.
มีสองวิธีแก้ไขที่ทำงานร่วมกัน. Exponential backoff จะเว้นระยะห่างในการลองใหม่: รอ 1 วินาที, จากนั้น 2, จากนั้น 4, จากนั้น 8, เพิ่มเป็นสองเท่าไปจนถึงค่าสูงสุด. บริการมีพื้นที่สำหรับการกู้คืนแทนที่จะถูกถล่มด้วยการลองใหม่ทันที. Jitter จะเพิ่มค่าออฟเซ็ตแบบสุ่มในการรอแต่ละครั้ง เพื่อให้ไคลเอ็นต์นับพันที่ล้มเหลวพร้อมกันทั้งหมด จะไม่ลองใหม่พร้อมกันทั้งหมด. หากไม่มี Jitter, Backoff ก็ยังคงสร้างคลื่นที่ซิงโครไนซ์กัน.
จำกัดสองสิ่ง: การหน่วงเวลา เพื่อที่คุณจะได้ไม่ต้องรอนานหลายนาทีระหว่างการลอง และจำนวนครั้งที่ลอง เพื่อให้ข้อผิดพลาดถาวรยอมแพ้แทนที่จะลองใหม่ตลอดไป. การลองสามถึงห้าครั้งครอบคลุมข้อผิดพลาดชั่วคราวเกือบทั้งหมด. เกินกว่านั้นคุณมักจะลองใหม่ในสิ่งที่ไม่มีทางสำเร็จ. Anthropic SDK ทำส่วนหนึ่งของสิ่งนี้สำหรับการเรียกใช้ของตัวเอง: มันลองใหม่ข้อผิดพลาดในการเชื่อมต่อและรหัสสถานะเฉพาะด้วย Exponential backoff และคุณกำหนดค่าสูงสุดด้วยตัวเลือก max-retries. แต่ไม่ครอบคลุม API อื่นๆ ที่เครื่องมือของเอเจนต์ของคุณเรียกใช้ ดังนั้นคุณต้องจัดการเอง. ทีมที่ใช้เงินผ่านการลองใหม่จะเรียนรู้สิ่งนี้ตั้งแต่เนิ่นๆ และการวิเคราะห์ ตรรกะการลองใหม่สำหรับ API ที่มีความเสี่ยงสูง ของเราแสดงให้เห็นว่าการลองใหม่ที่ประมาทสร้างความเสียหายจริงได้อย่างไร.
ตั้งค่าการหมดเวลาในการเรียกใช้ทุกครั้ง
การลองใหม่จะช่วยได้ก็ต่อเมื่อคำขอล้มเหลวเท่านั้น. กรณีที่แย่กว่านั้นคือคำขอที่ไม่เคยกลับมา: การพึ่งพา (dependency) ยอมรับการเชื่อมต่อของคุณ แล้วก็ค้างไป. หากไม่มีการตั้งค่าหมดเวลา การเรียกใช้เครื่องมือจะถูกบล็อก และการทำงานทั้งหมดจะหยุดชะงักอยู่เบื้องหลัง Socket ที่ตายไปหนึ่งจุด. ไม่มีข้อผิดพลาด ไม่มีการกู้คืน มีเพียงเอเจนต์ที่ค้างอยู่ ซึ่งเผาผลาญเวลาจริงและงบประมาณโทเค็นไปเปล่าๆ.
การเรียกออกทั้งหมดจำเป็นต้องมีการตั้งค่าหมดเวลา. ตั้งค่าการหมดเวลาในการเชื่อมต่อสำหรับการสร้างการเชื่อมต่อ และการหมดเวลาในการอ่านสำหรับการรอการตอบสนอง จากนั้นตั้งงบประมาณรวมสำหรับการทำงานของเอเจนต์ทั้งหมด เพื่อให้การเรียกที่ช้าแต่ถูกต้องตามกฎหมายไม่สามารถเกินความอดทนของผู้ใช้ได้. เมื่อการหมดเวลาเกิดขึ้น ให้จัดการเหมือนข้อผิดพลาดที่สามารถลองใหม่ได้อื่นๆ: ถอยหลัง (back off) แล้วลองใหม่อีกครั้ง จนกว่าจะถึงขีดจำกัดของคุณ.
เลือกตัวเลขจากเวลาแฝงจริง ไม่ใช่การคาดเดา. ตั้งค่าการหมดเวลาแต่ละครั้งให้สูงกว่า p99 ของ dependency โดยมีพื้นที่เผื่อไว้. ถ้าตั้งแน่นเกินไป คุณจะยกเลิกการเรียกที่ควรจะสำเร็จ. ถ้าตั้งหลวมเกินไป dependency ที่ค้างอยู่จะทำให้เอเจนต์ติดอยู่เป็นเวลานานเกินกว่าที่จะมีประโยชน์. ให้การตอบสนองแบบ Streaming มีงบประมาณของตัวเอง เนื่องจากกระบวนการที่ใช้เวลานานนั้นช้าอย่างถูกต้องตามกฎหมาย และการหมดเวลาที่สั้นและคงที่ก็จะตัดมันกลางคัน.
เรียกใช้งาน Circuit Breaker เมื่อ Dependency ล่ม
Backoff จัดการบริการที่ยุ่งอยู่ชั่วขณะ. มันเป็นเครื่องมือที่ไม่ถูกต้องสำหรับบริการที่ล่มอย่างสมบูรณ์. หาก dependency ล้มเหลวมาเป็นนาทีแล้ว คำขอถัดไปก็เกือบจะล้มเหลวด้วยเช่นกัน และการลองใหม่จะเพิ่มภาระให้กับสิ่งที่เสียอยู่แล้ว ในขณะที่ผู้ใช้รอความล้มเหลวที่คุณสามารถคาดเดาได้.
Circuit Breaker แก้ไขปัญหานี้ด้วยสามสถานะ. Closed คือปกติ: คำขอไหลผ่านและตัว Breaker นับความล้มเหลว. เมื่อความล้มเหลวเกินเกณฑ์ มันจะเปลี่ยนไปสู่สถานะ Open: มันหยุดส่งคำขอและล้มเหลวอย่างรวดเร็วในช่วงเวลา Cool-down เพื่อที่คุณจะได้ไม่ต้องเสียเวลาในการหมดอายุ (timeout) ทุกครั้งที่เรียกใช้บริการที่ตายไปแล้ว. หลังจากช่วงเวลานั้น มันจะเข้าสู่สถานะ Half-open และอนุญาตให้มีการตรวจสอบ (probe) เพียงครั้งเดียวผ่านไป. หากการตรวจสอบสำเร็จ ตัว Breaker จะปิดลงและการจราจรจะกลับมาทำงานต่อ; หากล้มเหลว มันจะเปิดอีกครั้งและรอ.
สำหรับเอเจนต์ ตัว Breaker จะเปลี่ยน "API การชำระเงินล่ม" ให้กลายเป็นความล้มเหลวที่รวดเร็วและชัดเจนที่เอเจนต์สามารถวิเคราะห์ได้ แทนที่จะเป็นการหมดเวลาที่ช้าสี่สิบครั้งที่ทำให้งบประมาณโทเค็นและเวลาหมดไป. เชื่อมต่อมันต่อ Dependency ไม่ใช่ทั่วโลก เพื่อให้ Search API ที่ล่มไม่หยุดเอเจนต์จากการใช้ Billing API ที่ทำงานปกติ.
ทำให้การลองใหม่ปลอดภัยด้วย Idempotency Keys
ทุกรูปแบบที่กล่าวมานั้นถือว่าการลองใหม่นั้นปลอดภัย. แต่บ่อยครั้งที่มันไม่ปลอดภัย. เอเจนต์ของคุณส่ง POST /charge, เซิร์ฟเวอร์ประมวลผล และการตอบสนองหมดเวลาขณะส่งกลับมา. เอเจนต์ไม่เคยเห็นความสำเร็จ ดังนั้นมันจึงลองใหม่ และตอนนี้ลูกค้าถูกเรียกเก็บเงินสองครั้ง. การลองใหม่ทำตามที่คุณขอทุกประการ. การออกแบบนั้นคือข้อผิดพลาด.
Idempotency key ช่วยปิดช่องว่างนี้. ไคลเอ็นต์สร้างคีย์ที่ไม่ซ้ำกันสำหรับการดำเนินการเชิงตรรกะแต่ละครั้ง และส่งไปพร้อมกับคำขอ โดยปกติจะอยู่ในส่วนหัว Idempotency-Key. เซิร์ฟเวอร์จะบันทึกคีย์เมื่อได้รับครั้งแรก และหากเห็นคีย์เดิมอีกครั้ง จะส่งคืนผลลัพธ์เดิมแทนที่จะทำงานซ้ำสองครั้ง. ตอนนี้การลองใหม่ปลอดภัยโดยการออกแบบ: POST /charge ครั้งที่สองที่มีคีย์เดียวกันจะเป็นการดำเนินการที่ไม่ทำอะไร (no-op) ซึ่งจะส่งคืนการเรียกเก็บเงินครั้งแรก.
คีย์จะต้องคงที่ตลอดการลองใหม่ของการกระทำเดียวกัน และเปลี่ยนไปเมื่อเป็นการกระทำที่แตกต่างกัน. สร้างคีย์เพียงครั้งเดียวเมื่อคุณสร้างคำขอ ไม่ใช่ภายในวงจรการลองใหม่ มิฉะนั้นการลองแต่ละครั้งจะได้รับคีย์ใหม่และจะไม่มีการตัดซ้ำ. การเรียกใช้เครื่องมือใดๆ ที่สร้างหรือเปลี่ยนแปลงสถานะ (การเรียกเก็บเงิน, คำสั่งซื้อ, อีเมล, บันทึก) จำเป็นต้องมีคีย์นี้. คู่มือของเราเกี่ยวกับ Idempotency Keys ครอบคลุมการสร้างและการจัดการฝั่งเซิร์ฟเวอร์อย่างครบถ้วน.
เอาชนะข้อจำกัดอัตรา (Rate Limits) และวงจร RateLimitError
ข้อจำกัดอัตรา (Rate Limits) สมควรได้รับการจัดการเป็นพิเศษ เพราะมาพร้อมกับคำแนะนำ. การตอบสนองแบบ เกินขีดจำกัดอัตรา มักจะมาในรูปแบบ 429 พร้อมส่วนหัว Retry-After ที่บอกคุณว่าต้องรอนานเท่าใด อย่างแม่นยำ เป็นวินาทีหรือเป็นวันที่. เคารพมัน. หากเซิร์ฟเวอร์บอกให้รอ 30 วินาที และคุณลองใหม่ใน 2 วินาที คุณจะได้รับ 429 อีกครั้ง และคุณก็ได้สร้างวงจร RateLimitError ที่เต็มกระดานสนทนาของ SDK: ดักจับข้อจำกัด, ลองใหม่เร็วเกินไป, ถูกจำกัดหนักขึ้น, ทำซ้ำจนกว่าการทำงานจะหยุดลง. เธรด SDK แยกต่างหาก ครอบคลุมปัญหาเดียวกันที่นักพัฒนาพบที่นี่.
วิธีแก้ไขคือการให้เซิร์ฟเวอร์เป็นผู้กำหนดจังหวะ. เมื่อคุณได้รับ 429 ให้อ่าน Retry-After และรออย่างน้อยตามระยะเวลานั้นก่อนที่จะลองใหม่. หากไม่มีส่วนหัวดังกล่าว ให้กลับไปใช้ Exponential backoff พร้อม Jitter. กำหนดขีดจำกัดการพยายามเพื่อให้ข้อจำกัดที่ยั่งยืนสิ้นสุดลงด้วยความล้มเหลวที่ชัดเจน แทนที่จะเป็นการรอที่ไม่มีที่สิ้นสุด. Anthropic SDK เคารพ Retry-After สำหรับการเรียกของตัวเองอยู่แล้ว; สิ่งที่ต้องทำคือการใช้กฎเดียวกันกับ API ที่จำกัดอัตราอื่นๆ ที่เอเจนต์ของคุณเรียกใช้.
นอกจากนี้ยังมีด้านเชิงรุกด้วย. หากผู้ให้บริการอนุญาตจำนวนคำขอที่กำหนดต่อนาที ให้วัดการเรียกของคุณเองด้วย Token Bucket เพื่อให้คุณยังคงอยู่ภายใต้ขีดจำกัด แทนที่จะพบว่ามันถูกจำกัด. การกู้คืนจัดการกับข้อจำกัดที่คุณเจอ; การกำหนดจังหวะช่วยให้คุณไม่ไปเจอข้อจำกัดเหล่านั้น.
วิธีทดสอบเส้นทางการกู้คืน
ตอนนี้มาประกอบรวมกัน. รูปแบบข้างต้นจะดีได้ก็ต่อเมื่อมีหลักฐานว่ามันทำงานได้จริง และหลักฐานนั้นคือการทดสอบที่บังคับให้เกิดความล้มเหลวที่ API ที่ทำงานปกตินั้นไม่สามารถให้คุณได้. รูปแบบนี้สามารถนำไปใช้ซ้ำได้ในทุกสถานการณ์:
- สร้าง Mock ของ Dependency. สร้าง Mock ของ API ที่เครื่องมือของเอเจนต์ของคุณเรียกใช้ เพื่อให้คุณสามารถควบคุมรหัสสถานะ, ส่วนหัว, เนื้อหา (body) และการหน่วงเวลาทั้งหมด และไม่มีการเรียกเก็บเงินจริงหรือส่งอีเมลระหว่างการทดสอบ.
- ตั้งโปรแกรมลำดับ. เขียนสคริปต์ให้ Mock ตอบกลับการเรียกชุดหนึ่งตามลำดับ: ครั้งแรกเป็น 429 พร้อม
Retry-After: 2, จากนั้นเป็น 500, จากนั้นเป็น 200 พร้อมเนื้อหาที่ถูกต้อง. หนึ่งปลายทาง, สามการตอบสนองที่กำหนดไว้, เส้นทางการกู้คืนที่สมบูรณ์ในการรันครั้งเดียว. - ขับเคลื่อนเอเจนต์ไปยัง Mock. ชี้เครื่องมือของเอเจนต์ไปยัง URL ของ Mock แทนบริการจริง และรันสถานการณ์ตั้งแต่ต้นจนจบ.
- ยืนยันพฤติกรรม. ตรวจสอบสิ่งที่สำคัญ: เอเจนต์รออย่างน้อย 2 วินาทีหลังจาก 429 ก่อนที่จะลองใหม่, ลองใหม่หลังจาก 500, สำเร็จในการเรียกครั้งที่สาม, และไม่เคยเกินขีดจำกัดการพยายามของคุณ.
สถานการณ์นั้นพิสูจน์การทำงานของ Backoff และ Retry-After ได้ในการดำเนินการครั้งเดียว. เพิ่มสถานการณ์ที่สองสำหรับเส้นทางการยอมแพ้ (give-up path): เขียนสคริปต์ให้ Mock ล้มเหลวทุกครั้ง และยืนยันว่าเอเจนต์หยุดที่ขีดจำกัดและส่งคืนข้อผิดพลาดที่ชัดเจนแทนที่จะวนซ้ำ. เพิ่มสถานการณ์ที่สามสำหรับ Circuit Breaker: ทำให้การเรียกจำนวนมากติดต่อกันล้มเหลว และยืนยันว่าเอเจนต์ทำงาน (trip) และล้มเหลวอย่างรวดเร็ว แทนที่จะต้องเสียเวลาหมดอายุ (timeout) ในการพยายามทุกครั้ง.
การตรวจสอบ Idempotency เป็นสิ่งที่คนส่วนใหญ่ข้ามไป และเป็นสิ่งที่ช่วยประหยัดเงิน. เขียนสคริปต์ให้ Mock ยอมรับการเรียกที่เปลี่ยนแปลงสถานะ (mutating call), ละทิ้งการตอบสนองเพื่อให้เอเจนต์คิดว่าล้มเหลว, จากนั้นยอมรับการลองใหม่. ตอนนี้ยืนยันรูปร่างของคำขอ: คำขอทั้งสองมี Idempotency-Key เดียวกัน และ Mock เห็นการกระทำเชิงตรรกะเพียงครั้งเดียว ไม่ใช่สองครั้ง. คีย์ใหม่ในการลองใหม่ หรือการเรียกซ้ำกัน หมายความว่าคุณพบการส่งซ้ำสองครั้งก่อนที่ลูกค้าจะพบ. วิธีการที่กว้างขึ้นสำหรับ การทดสอบเอเจนต์ที่เรียกใช้ API ของคุณ จะตั้งค่าการทดสอบตั้งแต่ต้นจนจบ.
รายการตรวจสอบการกู้คืนข้อผิดพลาด
- การเรียกออกทั้งหมดมีการหมดเวลาในการเชื่อมต่อ (connect timeout), การหมดเวลาในการอ่าน (read timeout) และงบประมาณการทำงานรวม.
- การลองใหม่ใช้ Exponential Backoff พร้อม Jitter โดยจำกัดทั้งการหน่วงเวลาและจำนวนครั้งที่พยายาม.
- การตอบสนอง 429 จะอ่านและเคารพ
Retry-Afterโดยมี Backoff เป็นทางเลือกสำรอง. - Circuit Breaker จะทำงานต่อ Dependency เพื่อให้บริการที่ล่มล้มเหลวอย่างรวดเร็วแทนที่จะวนซ้ำ.
- การเรียกที่เปลี่ยนแปลงสถานะทุกครั้งจะมาพร้อมกับ Idempotency Key ที่เสถียรซึ่งคงอยู่ในการลองใหม่.
- เส้นทางการยอมแพ้ (give-up path) จะส่งคืนข้อผิดพลาดที่ชัดเจน ไม่ใช่การรอที่ไม่มีที่สิ้นสุด.
- แต่ละข้อเหล่านี้ได้รับการพิสูจน์โดยการทดสอบที่บังคับให้เกิดความล้มเหลวกับ Mock ไม่ใช่การสันนิษฐานเอาเอง.
ทำเครื่องหมายทั้งเจ็ดข้อนี้ แล้วเอเจนต์ของคุณจะกู้คืนได้โดยเจตนา ไม่ใช่ด้วยโชค.
Apidog เหมาะสมกับอะไร (และไม่เหมาะสมกับอะไร)
รักษาหน้าที่ของเครื่องมือให้ซื่อสัตย์. Apidog ไม่ใช่เฟรมเวิร์กเอเจนต์, โฮสต์โมเดล, หรือรันไทม์. ไม่ได้สร้าง, รัน, หรือจัดการเอเจนต์ของคุณ และไม่ได้ให้คะแนนเอาต์พุตของโมเดล. สิ่งที่ Apidog เป็นเจ้าของคือเลเยอร์ API ที่เอเจนต์ของคุณเรียกใช้ ซึ่งเป็นจุดที่การกู้คืนจะสำเร็จหรือล้มเหลว.
นั่นทำให้ Apidog มีสามหน้าที่. หนึ่งคือ Mock Dependency ที่เอเจนต์ของคุณเรียกใช้ เพื่อให้คุณได้ Stand-in ที่ควบคุมได้แทนบริการจริง. สองคือตั้งโปรแกรมการตอบสนองความล้มเหลว (429 พร้อม Retry-After, 500, หมดเวลา, Body ที่ผิดรูปแบบ) ที่ API จริงจะไม่ส่งคืนตามคำสั่ง เพื่อให้คุณสามารถฝึกซ้อมการกู้คืนได้. และสามคือตรวจสอบความถูกต้องของคำขอที่ Mock ได้รับ (Idempotency Key มีอยู่และเสถียร, รูปร่างถูกต้อง, จำนวนการเรียกที่คาดไว้) เพื่อให้การส่งซ้ำสองครั้งหรือ Header ที่หายไปทำให้การทดสอบล้มเหลว แทนที่จะเป็นลูกค้า. นั่นคือความเหมาะสมที่ซื่อสัตย์: Apidog จำลองความล้มเหลวที่เอเจนต์ของคุณต้องเอาชีวิตรอด และตรวจสอบสิ่งที่ส่งกลับไป.
คำถามที่พบบ่อย
Anthropic SDK ไม่จัดการการลองใหม่ให้ฉันหรอกหรือ? สำหรับการเรียกใช้ของตัวเอง ใช่. SDK จะลองใหม่ข้อผิดพลาดบางอย่างด้วย Exponential Backoff และเคารพ Retry-After และคุณสามารถตั้งค่าสูงสุดด้วยตัวเลือก max-retries. แต่ไม่ครอบคลุม API อื่นๆ ที่เครื่องมือของเอเจนต์ของคุณเรียกใช้. API เหล่านั้นต้องการรูปแบบเดียวกันที่คุณต้องนำไปใช้เอง.
เมื่อไหร่ที่ฉันต้องการ Idempotency key? ในการเรียกใช้ใดๆ ที่สร้างหรือเปลี่ยนแปลงสถานะ: การเรียกเก็บเงิน, คำสั่งซื้อ, ข้อความที่ส่ง, บันทึกใหม่. การเรียกอ่านอย่างเดียว (Read-only calls) ปลอดภัยที่จะลองใหม่ได้โดยไม่จำเป็นต้องมีคีย์. สร้างคีย์หนึ่งครั้งต่อการกระทำเพื่อให้คีย์คงที่ตลอดการลองใหม่.
ฝึกซ้อมความล้มเหลวหนึ่งครั้งในสัปดาห์นี้
คุณไม่จำเป็นต้องสร้างทั้งสี่รูปแบบพร้อมกัน. เลือกรูปแบบที่น่าจะสร้างความเสียหายมากที่สุด โดยปกติคือวงจรการจำกัดอัตรา (rate-limit loop) หรือการลองใหม่ที่ไม่ใช่ Idempotent, แล้วฝึกซ้อมกับ Mock. ตั้งโปรแกรม 429, ละทิ้งการตอบสนอง, และดูว่าเอเจนต์ส่งอะไรไป. ครั้งแรกที่คุณเห็น Backoff ที่สะอาดตาและ Idempotency Key เดียว แทนที่จะกังวลเรื่องการเรียกเก็บเงินซ้ำซ้อน คุณจะเชื่อมั่นในเอเจนต์ด้วยเหตุผลที่ดีกว่าการสาธิตที่ราบรื่น.
ดาวน์โหลด Apidog เพื่อจำลองความล้มเหลว, สร้างสคริปต์ลำดับ, และยืนยันพฤติกรรมของเอเจนต์ของคุณเมื่อ API ตอบสนองกลับมา.