背景

1. TEN Extension目前的几个生命周期回调：

• on_configure & on_init : 配置&资源初始化
• on_start : 启动
• on_stop : 停止
• on_deinit: 资源销毁

2. TEN Extension 的生命周期流转目前是依靠runtime自动触发，且同一张图里的extension生命周期流转也都是独立的。

3. 实际业务中存在需要管控Extension启动/停止时机并做一些顺序控制，例如：

• 插件按需启动/延迟启动：
  stt业务中动态决定是否开启translator/vtt功能。（也可以通过不同图来决定）

• 顺序启动：
  先启动billing, report, 再启动RTC, ASR 避免漏计量/上报

• 顺序停止：
  最后停billing, report避免漏计量/上报

目标

TEN提供机制管控extension的生命周期，从框架层面解决上面场景的问题。

实现

新增手动控制Extension启停的模式配置项

extension node

graph里的extension node property ten field 里新增 manual_trigger_life_cycle 属性，array类型。 示例：

可选项： configure/init/start/stop/deinit
本期实现： start/stop

{
  "type": "extension",
  "name": "simple_http_server_cpp",
  "addon": "simple_http_server_cpp",
  "extension_group": "default_extension_group",
  "property": {
    "server_port": 8002,
    "ten": {
      "manual_trigger_life_cycle": [
        {
          "stage": "start"
        },
        {
          "stage": "stop"
        }
      ]
    }
  }
},

设定了manual_trigger_life_cycle的extension对应阶段生命周期不会自动流转，而是在收到对应的 ten:trigger_life_cycle cmd 时才会流转。

subgraph node

subgraph node不会声明 manual_trigger_life_cycle，其内部extension node 可以声明 manual_trigger_life_cycle。

如果想要手动trigger subgraph的生命周期，需要subgraph内有extension声明 manual_trigger_life_cycle，且subgraph通过 exposed_messages 声明收到的 ten:trigger_life_cycle cmd会转发给subgraph内部的extension。

subgraph.json:

{
  "nodes": [
    {
      "type": "extension",
      "name": "main",
      "addon": "default_extension_python",
      "extension_group": "main",
      "property": {
        "ten": {
          "manual_trigger_life_cycle": [
            {
              "stage": "start"
            },
            {
              "stage": "stop"
            }
          ]
        }
      }
    },
    {
      "type": "extension",
      "name": "biz",
      "addon": "default_extension_python",
      "extension_group": "biz",
      "property": {
        "ten": {
          "manual_trigger_life_cycle": [
            {
              "stage": "start"
            },
            {
              "stage": "stop"
            }
          ]
        }
      }
    }
  ],
  "exposed_messages": [
    {
      "type": "cmd_in",
      "name": "function_call",
      "extension": "main"
    },
    {
      "type": "cmd_in",
      "name": "ten:trigger_life_cycle",
      "extension": "main"
    }
  ],
  "exposed_properties": [
    {
      "name": "base",
      "extension": "main"
    }
  ]
}

由于发送cmd给subgraph的功能我们还没做，所以这块目前仅停留在设计，暂时不会实现。

selector node

不支持手动管理其生命周期。

新增控制Extension启停的特殊cmd

新增 ten:trigger_life_cycle cmd，该cmd不能通过graph连线指定，只能通过set_dest 发送。

ten:trigger_life_cycle cmd 有一个字段：

• stage: "configure", "start", "init", "stop", "deinit"

实现逻辑

1. runtime 在 parse graph 的时候, 在 extension_info 内纪录要手动触发的 life cycle stages
2. runtime 运行的时候, 当运行到准备要触发指定的 extension 的 life cycle callbacks (on_xxx) 的时候，判断有没有收到触发 cmd, 没收到就 return, 不要触发 on_xxx. 已经收到就继续触发 on_xxx
3. 等之后收到触发 cmd, 就触发 on_xxx
4. 当 on_xxx_done 的时候, 针对收到的 trigger cmd, 发送 cmd_result 回去
5. 在对应stage完成后才收到的trigger cmd, 直接回应失败，错误信息为空。

异常情况

由于stop_graph/close_app 导致跳过 on_xxx. 一样设定了手动模式的还是要等trigger cmd才行。

业务集成实践

需要手动启停的extension在图中配置 manual_trigger_life_cycle.

graph配套的main extension里要在on_start 里按顺序发送 ten:trigger_life_cycle ，收到result表示该extension on_start_done. 在on_stop 里按顺序发送 ten:trigger_life_cycle ，收到result表示该extension on_stop_done.

可能带来的问题

1. 如果一个 manual_trigger_life_cycle 的extension一直没有被手动停止，那么会一直卡住。（无论其是否有被手动启动过）

2. 收发msg的时机限制不变。

3. 即使 on_start 没有被调用过，on_stop 也是会被调用的。（现状已经是这样了，例如某个extension还在初始化阶段app就被close了）