Cloudflare Computer v0.7.0 กู้ JavaScript หลัง Crash และหยุดรออนุมัติได้: ระวัง Side Effect ซ้ำ

Cloudflare ประกาศเมื่อ 26 ตุลาคม 2026 ว่า @cloudflare/computer ตั้งแต่ v0.7.0 ช่วยให้งาน JavaScript ของ Agent กลับมาทำต่อหลัง deploy หรือ crash และหยุดรอการตอบจากแอปภายนอก เช่นการอนุมัติ tool call ได้ ความสามารถนี้เหมาะกับงานที่ไม่ได้จบในคำขอสั้น ๆ แต่ผู้พัฒนาต้องออกแบบการกระทำที่อาจถูกเรียกซ้ำให้ชัดเจน

Replay ไม่ได้หมายถึงทุกคำสั่งเกิดครั้งเดียว

เมื่อเปิด onInterrupt: replay บน WorkerJavaScriptBackend การกู้คืนจะรัน JavaScript ใหม่จากต้นและนำผลที่บันทึกแล้วกลับมาใช้ แต่หากการกระทำสำเร็จก่อนผลถูกบันทึก การกู้คืนอาจเรียกการกระทำนั้นซ้ำได้ นี่คือข้อจำกัดสำคัญที่ต้องประเมินก่อนใช้กับงานส่งข้อความ สร้างรายการ หรือเปลี่ยนข้อมูลภายนอก

ตัวอย่างที่ควรซ้อมคือ API ปลายทางรับงานแล้วแต่ connection ขาดก่อน runtime เก็บผล หาก retry สร้างรายการใหม่ทุกครั้ง ผู้ใช้อาจเห็นงานซ้ำ ทีมควรใช้ idempotency ของปลายทางหรือวิธีตรวจการกระทำเดิมที่เหมาะกับระบบนั้น และอ่านข้อกำหนด unsafeToRepeat() สำหรับงานที่ทำซ้ำอย่างปลอดภัยไม่ได้

จุดอนุมัติต้องผูกกับสิ่งที่จะเกิดขึ้นจริง

custom module สามารถเรียก ctx.interrupt() เพื่อหยุดรอผลจากแอปของผู้พัฒนาได้ การมีจุดหยุดยังไม่แทนหน้าจอหรือระบบสิทธิ์ของผู้อนุมัติ ทีมต้องแสดงว่า Agent จะทำอะไรกับข้อมูลใด และตรวจว่าคนที่ตอบมีอำนาจตัดสินใจสำหรับงานนั้น

หากรายละเอียดงานเปลี่ยนหลังขออนุมัติ เช่นข้อความที่จะโพสต์หรือรายการที่จะบันทึก ควรตรวจว่าผลอนุมัติเดิมยังใช้ได้กับการกระทำปัจจุบันหรือไม่ อย่าให้ข้อความสรุปที่คลุมเครือกลายเป็นการอนุมัติแบบครอบคลุมทุกคำสั่งที่ Agent เลือกในภายหลัง

การรอที่อยู่รอดหลัง Deploy ต้องจัดการคิวให้ครบ

ประกาศระบุว่าช่วงรอไม่ถูกนับเข้า timeout และยังอยู่ต่อหลัง deploy แอปสามารถอ่าน pending calls และตอบผ่าน respond() ก่อนงานเดินต่อเมื่อทุก call ที่ค้างได้รับคำตอบ ผลเชิงออกแบบคือทีมควรมีเจ้าของคิว สถานะที่ผู้ใช้เข้าใจ และทางจัดการงานที่ไม่มีผู้ตอบเป็นเวลานาน

ควรทดสอบทั้งอนุมัติ ปฏิเสธ และกรณีผู้ใช้พยายามตอบซ้ำ บันทึกว่าใครตอบเมื่อใดโดยไม่เก็บ secret ที่ไม่จำเป็นใน payload ของคำขออนุมัติ หากแอปมีหลาย tenant ต้องตรวจว่ารายการ pending ของแต่ละกลุ่มแยกกันถูกต้องก่อนเปิดให้ผู้ใช้จริง

Recovery ต้องมีตัวกระตุ้นที่แน่นอน

การกู้คืนเริ่มเมื่อมีการเรียก workspace.runtime ครั้งถัดไป หากต้องการไม่รอ traffic สามารถใช้ Durable Object alarm เรียก recover() ตามแนวทางเอกสาร ทีมควรเลือกให้ตรงรูปแบบงาน: งานที่มีคนกลับมาเปิดหน้าจอบ่อยอาจต่างจากงานเบื้องหลังที่ไม่มีคำขอใหม่หลัง crash

ในชุดทดสอบ ควรขัดจังหวะก่อน call ระหว่างรอผล และหลังปลายทางสำเร็จแต่ก่อนเก็บผล แล้วตรวจจำนวนการกระทำจริงที่ระบบภายนอกได้รับ การดูเพียงสถานะ runtime ว่า completed ไม่ยืนยันว่าไม่มี side effect ซ้ำ

แยก Runtime ที่ทนขัดข้องออกจากนโยบายของ Agent

ความสามารถนี้ช่วยกลไกทำงานต่อและรอภายนอก แต่ไม่ได้กำหนดว่า Agent ควรมีสิทธิ์ใดหรือเป้าหมายใดถูกต้อง ผู้พัฒนายังต้องจำกัดเครื่องมือ ตรวจ input และกำหนดจุดหยุดตามผลกระทบของงาน การทดสอบกับข้อมูลจำลองและปลายทางที่ควบคุมได้ก่อนจะช่วยให้รู้ว่าการกู้คืนรักษาทั้งผลลัพธ์และขอบเขตสิทธิ์ได้จริง

แหล่งต้นทาง: Cloudflare Computer durable JavaScript announcement ประกาศวันที่ 26 ตุลาคม 2026