如何处理Twilio呼叫中Widget执行时的Hangup事件（Error-81002）

首先明确：Twilio Functions无法在内部直接捕获呼叫的Hangup事件。当用户挂断呼叫时，Twilio会立即终止当前正在执行的函数请求，函数进程会被强制停止，没有机会执行后续的捕获逻辑。这也是Error-81002的核心原因——呼叫上下文已销毁，流程无法继续流转到下一环节。

以下是几个可行的处理方案：

• 配置全局Hangup事件处理
  在Studio Flow的触发器面板中，找到「On Hangup」触发器，为它配置独立的处理流程（比如记录呼叫结束日志、清理关联资源等）。不管呼叫在哪个环节被挂断，Flow都会自动触发这个分支，避免因流程中断抛出Error-81002。

• 函数执行前检查呼叫状态
  在调用目标函数的Widget之前，新增一个「Run Function」或「Make HTTP Request」Widget，调用Twilio的呼叫查询API获取当前呼叫状态。如果状态不是in-progress，直接跳转到Hangup处理流程；只有状态正常时，才继续执行后续的函数逻辑。

• 函数逻辑做幂等性设计
  如果函数包含关键业务操作（比如数据库写入），要确保逻辑是幂等的。比如用呼叫SID作为唯一标识，执行操作前先检查该呼叫是否已经处理过，避免因函数被中途终止后重试导致重复操作。

• 轻量化异常捕获与清理
  在函数内部用try-catch包裹核心逻辑，当函数因Hangup被强制终止时，在catch块中执行轻量化的清理操作（比如关闭数据库连接、记录错误日志到Twilio控制台）。注意：此时函数的执行时间会被严格限制，所以清理逻辑要尽可能简短。

Error-81002本质是呼叫生命周期结束后流程仍试图执行后续步骤导致的，核心思路是让流程能感知呼叫状态变化，提前分支处理，而不是强行在已销毁的呼叫上下文里继续执行。

内容的提问来源于stack exchange，提问作者ESK