Idempotency และ retry

ความน่าเชื่อถือใช้ identity สองชั้นซึ่งห้ามสับสนกัน

• Idempotency-Key ระบุ submission เดิมที่ payload ต้องเหมือนเดิมทุก byte เชิง canonical
• external_ref ระบุ business row เดิม แม้ส่งภายใต้ transport key ใหม่

เมื่อผลลัพธ์ไม่แน่ชัด

ถ้า connection หลุดหลัง CFO อาจรับ request แล้ว ให้โหลด canonical payload และ Idempotency-Key เดิมจาก durable outbox แล้วส่งซ้ำ ระบบต้องคืน job เดิมและไม่สร้าง business row เพิ่ม ห้ามสร้าง key ใหม่ เพียงเพราะไม่ได้รับ response

กรณีทดสอบบังคับ

1. same-key replay: key เดิม + payload เดิม → job เดิม
2. changed payload: key เดิม + payloadต่าง → IDEMPOTENCY_KEY_REUSED และต้องหยุด
3. business duplicate: key ใหม่ + external_ref เดิม → skipped_duplicate
4. new business: key ใหม่ + external_ref ใหม่ → สร้างหนึ่ง row
5. ERP restart: identity/hash ต้องอยู่ครบและ retry แล้วไม่ซ้ำ

429 และ retryable 5xx ต้องใช้ bounded backoff เมื่อมี Retry-After ให้รอตามค่านั้น การ retry ทุกครั้งต้อง ใช้ request ที่ freeze ไว้ ไม่ re-read ข้อมูล ERP จน payload เปลี่ยนกลางทาง