Cloudflare Workers ขยายเวลาให้คำขอค้างจบระหว่างอัปเดต Runtime เป็น 20 นาที

Cloudflare ปรับเวลาผ่อนผันให้คำขอและการเชื่อมต่อที่ยังทำงานอยู่ระหว่างอัปเดต Workers runtime จากเดิมสูงสุด 30 วินาทีเป็นสูงสุด 20 นาที ประกาศวันที่ 12 ตุลาคม 2026 การเปลี่ยนนี้มีผลกับแอปที่ตอบกลับนาน เช่น streaming AI, HTTP request ที่ต้องรอหลายขั้น และ WebSocket เพราะลดโอกาสที่งานถูกตัดกลางทางทันทีเมื่อ runtime เปลี่ยนรุ่น แต่คำว่า “สูงสุด” ไม่ใช่สัญญาว่าทุก connection จะอยู่ครบ 20 นาที

runtime เปลี่ยนรุ่นอย่างไร

เมื่อ runtime รุ่นใหม่พร้อมรับงาน คำขอ HTTP ใหม่จะไปยังรุ่นใหม่ ส่วน process รุ่นเดิมหยุดรับคำขอใหม่แล้วค่อยระบายงานที่ค้างอยู่ Cloudflare ให้เวลาแก่ process รุ่นเก่าแต่ละตัวสูงสุด 20 นาที หากหมดเวลายังมีคำขอหรือการเชื่อมต่อค้างอยู่ งานนั้นจะถูกยุติ ดังนั้นการเปลี่ยนนี้ช่วยให้โอกาสทำงานจบสูงขึ้น แต่ไม่ได้ขจัดความจำเป็นในการจัดการการตัดการเชื่อมต่อ

ตัวอย่างที่เห็นผลชัดคือ API ที่ส่งผลลัพธ์แบบ Server-Sent Events และคำตอบจากโมเดลเป็น token ต่อเนื่อง เดิมการอัปเดต runtime อาจทำให้ผู้ใช้เห็นคำตอบขาดหลังเวลาสั้นมาก ระยะใหม่ช่วยให้ stream จำนวนมากจบตามธรรมชาติได้มากขึ้น อย่างไรก็ดี ถ้ากระบวนการใช้เวลานานกว่า 20 นาที หรือหลุดเพราะเหตุอื่น ก็ยังต้องมีการกู้สถานะ การ retry และวิธีบอกผู้ใช้ว่าผลลัพธ์สมบูรณ์หรือไม่

งานที่ต้องทำต่อในแอป

สำหรับ WebSocket ให้ client reconnect ด้วย backoff ที่มี jitter เพื่อหลีกเลี่ยงการ reconnect พร้อมกันจำนวนมากหลังมีการเปลี่ยน runtime เซิร์ฟเวอร์ควรผูก session กับข้อมูลที่บันทึกไว้และกลับไปอ่านสถานะหลังเชื่อมใหม่ แทนการเก็บข้อมูลสำคัญไว้เฉพาะในหน่วยความจำของ process เดิม Cloudflare ระบุว่า WebSocket อาจตัดก่อนหมดช่วงผ่อนผัน รวมถึงกรณีใช้ WebSocket Hibernation API ดังนั้นการทดสอบเฉพาะการอัปเดต runtime รอบเดียวไม่เพียงพอจะรับประกันความทนทาน

สำหรับ HTTP ที่เปลี่ยนข้อมูล ให้กำหนด idempotency key หรือวิธีตรวจว่าคำขอทำงานไปแล้วหรือยัง หาก client retry หลัง connection หลุดโดยไม่รู้ผลสุดท้าย อาจสร้างรายการซ้ำหรือเรียกเก็บเงินซ้ำ งานที่ใช้เวลานานมากควรแยกเป็น background job แล้วตอบรหัสงานให้ client ไปติดตาม แทนการถือ connection ค้างโดยไม่มี checkpoint ทั้งหมดนี้เป็นข้อควรออกแบบทั่วไปที่ยิ่งสำคัญเมื่อระบบมีการเปลี่ยน process ตามวงจรของแพลตฟอร์ม

วิธีวัดผลหลังเปลี่ยน

ทีมปฏิบัติการควรดูจำนวน stream ที่จบสำเร็จ อัตราการ disconnect ระหว่าง deploy หรือ runtime update ระยะเวลาของคำขอที่ยาวที่สุด และอัตรา reconnect ของ WebSocket เทียบช่วงก่อนหน้า การเพิ่ม grace period ไม่ควรทำให้ทีมปิด alert เกี่ยวกับการตัด connection เพราะยังอาจมี network failure, timeout จาก client, proxy หรือ upstream ที่ไม่ได้เปลี่ยนตามตัวเลขนี้ ควรทดสอบการตัดการเชื่อมต่อโดยตั้งใจใน staging และตรวจว่าผู้ใช้กลับไปทำงานต่อได้

สิ่งที่ประกาศไม่ได้บอกคือให้ใช้ 20 นาทีเป็นเวลาประมวลผลมาตรฐานของทุกงาน หรือรับประกันว่า session จะไม่ขาดระหว่างอัปเดต จึงควรแยกประโยชน์ของเวลาเผื่อออกจากสัญญาด้านความทนทานของแอป หากมีระบบที่กำลังย้ายจาก request สั้นไป streaming ยาว การเปลี่ยนครั้งนี้ทำให้ Workers รองรับการใช้งานจริงได้ดีขึ้น แต่สถาปัตยกรรมต้องยังคงรับมือการหยุดกลางทางได้

อ่านประกาศต้นทางวันที่ 12 ตุลาคม 2026: Cloudflare Changelog — More time for requests to finish during Workers runtime updates