หยุด runtime ของ UnifyPort โดยไม่ให้ระบบกู้คืนเปิดการเชื่อมต่ออีก
หากต้องการหยุดการเชื่อมต่อบัญชีรับส่งข้อความของ UnifyPort ชั่วคราวโดยไม่ลบบัญชี ให้ส่ง {} ไปยัง POST /v1/accounts/{account_id}/runtime/stop และยืนยันว่า runtime_status เป็น stopped ส่วน stopping ยังต้องตรวจสอบต่อ ก่อนเรียก API ควรแจ้งระบบกู้คืนของแอปว่าการหยุดนี้เป็นความตั้งใจ มิฉะนั้น worker ที่คอยรักษาการเชื่อมต่ออาจเปิดบัญชีกลับขึ้นมาอีก
ประเด็นสำคัญ
- การหยุด runtime ยังคงเก็บบัญชีไว้ ไม่ใช่การลบบัญชี
- บันทึกคำสั่งพักในพื้นที่จัดเก็บถาวรของแอปก่อนหยุดการเชื่อมต่อ
- สถานะ
runtime_statusที่สังเกตได้ กับการอนุญาตให้กู้คืน เป็นคนละเรื่องกัน - การเปิดการเชื่อมต่อใหม่ไม่ได้พิสูจน์ว่าข้อความระหว่างหยุดถูกกู้คืนแล้ว
การกู้คืนที่ถูกต้อง แต่อาจเกิดผิดเวลา
สมมติว่าผู้ดูแลหยุดบัญชีสำหรับงานบำรุงรักษาระบบบริการลูกค้าบน LINE จากนั้น worker ตรวจสุขภาพอ่านค่า stopped และเรียก start เพราะถูกออกแบบให้รักษาบัญชีให้ออนไลน์ นี่เป็นสถานการณ์ตัวอย่าง ไม่ใช่เหตุขัดข้องของลูกค้าที่รายงานจริง คำขอทั้งสองอาจถูกต้องตาม API แต่ขัดกับเจตนาของผู้ดูแล
วิธีแก้ไม่ใช่การเข้าสู่ระบบอีกครั้ง แต่คือการตัดสินใจร่วมกันในแอปว่า ขณะนี้บัญชีควรออนไลน์หรือไม่ คู่มือกู้คืน runtime อธิบายการกู้คืนการเชื่อมต่อที่ควรออนไลน์ ส่วนการหยุดตามแผนต้องเพิ่มเงื่อนไขควบคุมก่อนเริ่มตรรกะนั้น
เงื่อนไขนี้ไม่ใช่การตั้งค่า API ใหม่ เอกสารวงจรชีวิตบัญชี แยก status ของบัญชี สถานะการยืนยันตัวตน และ runtime_status ออกจากกัน บันทึกการพักที่เสนอในบทความเป็นข้อมูลของแอปเอง ไม่ใช่ฟิลด์ UnifyPort และไม่ใช่พฤติกรรมที่รับประกันจากการเปลี่ยน status ของบัญชี
เลือกก่อนว่าต้องหยุดส่วนใด
| เป้าหมาย | จุดควบคุมที่เหมาะสม |
|---|---|
| หยุดเขียน CRM หรือประมวลผล AI แต่ยังรับข้อความ | พัก consumer ของแอป |
| หยุดการเชื่อมต่อสดของบัญชี แต่เก็บบัญชีไว้ | Stop runtime |
| เลิกใช้และนำทรัพยากรบัญชีออก | กระบวนการลบบัญชีแยกต่างหาก |
หากบำรุงรักษาเฉพาะระบบปลายทาง ให้ดู การเปรียบเทียบวิธีพัก webhook และ worker การหยุดการเชื่อมต่อไม่ใช่วิธีพักข้อความไว้ในบัฟเฟอร์ถาวร
ใช้ คู่มือลบบัญชี เฉพาะเมื่อตั้งใจเลิกใช้ทรัพยากร ข้อกำหนดของ runtime stop ไม่ได้สัญญาว่าจะคืนเงิน พักสมาชิก ลบบัญชีบนแพลตฟอร์มต้นทาง หรือลบข้อความที่จัดเก็บไว้
ทำให้ worker เห็นคำสั่งพักก่อนส่งคำขอหยุด
ขั้นตอนต่อไปนี้เป็นคำแนะนำสำหรับการออกแบบแอป:
- ตรวจ workspace,
account_id, ช่องทาง ผู้ดำเนินการ และเหตุผล อ่านข้อมูลบัญชีกับสถานะยืนยันตัวตนแยกกัน - บันทึกคำสั่งพักสำหรับบัญชีนี้อย่างถาวร ให้ทั้ง worker กู้คืนและ worker ส่งข้อความตามกำหนดตรวจบันทึกก่อนส่งคำขอใหม่
- ประสานงานกับงานที่เริ่มแล้ว แฟล็กที่เพิ่งบันทึกไม่สามารถยกเลิก API request ที่ส่งออกไปแล้วได้ ใช้การประสานงานรายบัญชีของแอปและตรวจผลของคำขอที่ยังดำเนินอยู่
- เปิด receiver ของ webhook ไว้เพื่อยืนยันและบันทึกเหตุการณ์ที่ยังเข้ามา อย่าตีความ runtime stop ว่ารอจนการส่ง webhook ทั้งหมดเสร็จสิ้น
- ส่งคำขอหยุดที่ตรวจทานแล้วหนึ่งครั้ง จากนั้นตรวจผล
ตัวอย่างนี้เป็นรหัสเทียมของแอป ไม่ใช่ไวยากรณ์ SDK หรือ endpoint ใหม่:
ก่อนเรียก start หรือ reconnect อัตโนมัติ:
อ่านเจตนาการทำงานปัจจุบันของบัญชีจากข้อมูลภายในแอป
ถ้าผู้ดูแลสั่งพัก:
ไม่ส่งคำขอกู้คืน
ถ้าไม่ใช่:
ตรวจสถานะยืนยันตัวตนและ runtime
เลือกการกู้คืนตามเอกสาร
ทุกช่องทางกู้คืนต้องใช้เงื่อนไขเดียวกัน รวมถึงงานที่หน่วงเวลาและปุ่มกู้คืนด้วยมือ ประสานการเปลี่ยนคำสั่งพักและเปิดใหม่ เพื่อไม่ให้งาน start เก่ากลับมามีสิทธิ์ทำงานเพียงเพราะมีการเปลี่ยนหน้าจอภายหลัง
หยุดหนึ่งครั้ง แล้วตรวจสถานะจริง
เอกสาร Stop runtime ระบุให้ส่ง JSON object ว่าง ตัวอย่างต่อไปนี้ยังไม่ได้รันจริง กำหนดตัวแปรจากบัญชีที่ backend ตรวจแล้วและ API key ที่จัดเก็บอย่างปลอดภัย:
curl -X POST \
"https://api.unifyport.ai/v1/accounts/${UNIFYPORT_ACCOUNT_ID}/runtime/stop" \
-H "X-Api-Key: ${UNIFYPORT_API_KEY}" \
-H "Content-Type: application/json" \
-d '{}'
เก็บ API key ไว้ฝั่งเซิร์ฟเวอร์ บันทึก HTTP status และข้อมูลวินิจฉัยคำขอที่มี โดยไม่บันทึกความลับ
| สิ่งที่พบ | ความหมายและขั้นตอนถัดไป |
|---|---|
runtime_status: stopped | หยุดระดับ runtime แล้ว แต่ยังคงคำสั่งพักในแอป |
runtime_status: stopping | อยู่ระหว่างเปลี่ยนสถานะ ต้องตรวจต่อ |
| Timeout หรืออ่าน response ไม่ได้ | ยังไม่ทราบผล อ่านสถานะก่อนแก้ไขซ้ำ |
แอปยังสั่งพัก แต่ runtime กลับเป็น running | ตรวจเส้นทาง start หรือ reconnect ที่แข่งขันกัน อย่ารายงานว่าพร้อมบำรุงรักษาแล้ว |
ใช้ Get account หรือ Refresh runtime state เพื่อตรวจสอบ Refresh เป็นการซิงก์สถานะ ไม่ใช่การสั่งเริ่มใหม่ กำหนดนโยบายตรวจซ้ำและส่งต่อปัญหาที่มีขอบเขตในแอป โดยไม่สมมติระยะเวลาสิ้นสุดตายตัว
อย่ารอเหตุการณ์ account.stopped ที่ไม่มีในรายการสาธารณะ เอกสารวงจรชีวิตระบุว่า account.status.updated ไม่ได้รับประกันสำหรับทุกการเปลี่ยนสถานะจากคำขอ การไม่มีข้อความเข้าไม่ได้พิสูจน์ว่า runtime หยุดแล้ว
เปิดใช้งานใหม่เป็นการเปลี่ยนสถานะที่ต้องยืนยันแยกกัน
ยังคงระงับงานส่งข้อความขณะตรวจสถานะยืนยันตัวตนของบัญชี หากต้องให้ผู้ใช้ดำเนินการ ให้ทำตามขั้นตอนยืนยันตัวตนที่เกี่ยวข้อง เมื่อยืนยันสำเร็จ runtime มักเริ่มโดยอัตโนมัติ จึงไม่ควรเริ่มยืนยันตัวตนใหม่ระหว่างพักโดยไม่ตั้งใจ
หากการยืนยันยังใช้ได้และ runtime หยุดอยู่ ให้ใช้ Start runtime ประสานคำสั่งเปิดใหม่กับการควบคุมภายในแอป ตรวจจนเป็น running จริง เพราะ starting ยังไม่ใช่การเสร็จสิ้น
ก่อนปล่อยงานสะสม ตรวจว่าแต่ละงานยังเหมาะจะทำหรือไม่ ส่งข้อความทดสอบที่ควบคุมได้ แล้วติดตามเหตุการณ์ใหม่ผ่านการตรวจลายเซ็นและการจัดเก็บ จากนั้นจึงเปิด consumer และนโยบายกู้คืนอัตโนมัติที่ต้องการ
อินเทอร์เฟซที่ไม่เป็นทางการของ UnifyPort ไม่รับประกันการส่ง payload ที่พลาดซ้ำ และไม่มี REST API ทั่วไปสำหรับอ่านประวัติข้อความ บันทึกช่วงหยุดว่าอาจมีช่องว่างการรับข้อมูล การทดสอบข้อความใหม่สำเร็จพิสูจน์เพียงเส้นทางที่กลับมาทำงาน ไม่ใช่การเติมช่องว่างนั้น
คำถามที่พบบ่อย
Stop ลบบัญชีรับส่งข้อความหรือไม่?
ไม่ลบ เอกสารระบุว่าหยุด runtime โดยเก็บบัญชีไว้ การเริ่มใหม่เป็นอีกการกระทำหนึ่ง
Worker ควรเปิดทุกบัญชีที่เป็น stopped หรือไม่?
ไม่ควร ต้องตรวจว่าแอปต้องการให้บัญชีนั้นออนไลน์ในขณะนี้หรือไม่ สถานะ runtime ไม่ได้บอกเจตนาของผู้ดูแล
หยุดสำเร็จแล้วจะยกเลิกข้อความตอบกลับในคิวหรือ webhook หรือไม่?
อย่าสมมติเช่นนั้น จัดการงานในแอปแยกต่างหาก ข้อกำหนดสาธารณะไม่ได้สัญญาว่าจะยกเลิกงานที่ส่งไปแล้วหรือรอให้ webhook หมด
หยุดแล้วพักการคิดค่าบริการด้วยหรือไม่?
ข้อกำหนด runtime stop ไม่ได้สัญญาเรื่องนี้ อย่าใช้สถานะการเชื่อมต่อเป็นหลักฐานการเปลี่ยนแปลงทางการเงิน
ขั้นตอนต่อไปและแหล่งอ้างอิง
พัฒนาการควบคุมสิทธิ์กู้คืนร่วมกับ Stop runtime ทดสอบ worker ที่แข่งขันกัน คำขอ start ที่ยังทำงานอยู่ response หยุดที่สูญหาย สถานะ stopping การเปิดใหม่โดยตั้งใจ และข้อความตอบกลับเก่าในคิว รายการนี้เป็นข้อเสนอการทดสอบ ไม่ใช่ผลที่ผ่านแล้ว
ตรวจเอกสารเมื่อ 2026-11-04:
เปลี่ยนการเชื่อมต่อข้อความให้เป็น pipeline ผลิตภัณฑ์ที่เสถียร
เริ่มจากการส่งผ่าน API เดียว แล้วส่งข้อความขาเข้าทั้งหมดกลับสู่ระบบธุรกิจของคุณด้วย event มาตรฐาน