工作流事件
概述
事件用于定义流程的启动、等待和结束条件。本节说明事件类型与当前实现差异。
主要事件类型：
- 启动事件（无条件、消息、定时器）。
- 中间事件（消息/定时器/信号等）。
当前状态：
- 无动作中间事件已可自动推进；
- 定时器事件已支持到期推进、Cron、固定延迟/间隔、时区参数；
- 错误结束 / 终止结束事件已具备实例终止语义；
- 消息事件已支持按消息载荷命中等待节点，消息启动事件也可自动创建新实例；
- 默认部署下，主服务启动时已经会启用进程内定时扫描；如果需要跨进程或集群消息分发，仍需要接到真实消息总线或调度器。
后续实现要点示例：
- 消息启动：实现消息监听与路由，定义消息格式与消息-流程映射规则，支持幂等消费与重复消息过滤；
- 定时器启动/中间事件：在当前进程内扫描能力基础上，进一步实现可靠的持久化调度（支持进程重启恢复、时区与时间漂移处理）；
- 中间事件持久化：在任务等待状态保存事件订阅信息，并支持事件到达后的状态转换、超时与补偿逻辑；
- 错误处理与重试策略：定义失败重试、死信队列和告警路径；
下一步：与后端接口进一步统一生产级消息载荷、持久化结构与错误策略，然后分阶段补齐真实 Broker / Scheduler 接入文档与测试用例。
事件实现细节
消息契约（示例）:
{
"event_type": "order.created",
"workflow_key": "approve-order",
"payload": { "example": true },
"trace_id": "uuid",
"timestamp": 1670000000000
}
订阅与持久化：
- 在任务等待状态将事件订阅写入 DB（包含订阅 id、期望 event_type、条件表达式、有效期）；
- 事件总线接收消息时进行去重检查（trace_id 或幂等键），并找到匹配订阅进行触发。
定时器实现要点：
- 定时器应写入持久化队列（DB 表或持久化任务队列），并由 Scheduler 扫描或基于延迟队列触发；
- 实现时需处理时区、夏令时与系统时钟漂移；支持按 Cron 与固定延迟规则。
当前后端已经提供调度入口，并支持扫描定时启动事件；消息事件也已支持按 trace_id / 载荷哈希做基础去重。
当前服务启动后，会默认装配一套进程内事件运行时；后续如果需要接入真实消息系统，服务端可以替换默认消息总线实现，而不必重写工作流引擎本身。
对于当前局域网部署场景，系统默认采用“进程内消息总线 + 进程内定时扫描 + 数据库存状态”的方式运行，通常不需要额外部署独立消息队列。
错误处理与重试：
- 在处理事件或定时器时，若处理失败应有重试计数器与指数退避策略；
- 超过重试次数后将事件入死信队列并产生告警/人工介入流程。
示例用例与测试：
- 单元：事件订阅匹配逻辑、条件表达式评估、去重逻辑；
- 集成：消息生产→Broker→订阅触发→任务推进；
- 容错：Broker 中断、重复消息、服务重启后的恢复测试。