Conductor 工作流测试与验证实战Schema 校验、Mock 编排测试与真实执行三层防线【免费下载链接】conductorConductor is an event driven agentic workflow engine providing durable and highly resilient execution engine for applications and AI Agents项目地址: https://gitcode.com/GitHub_Trending/co/conductor导读在 Conductor 中工作流从定义能跑通到生产可用之间隔着三层验证Schema 校验定义是否正确、Mock 编排测试决策逻辑是否符合预期以及真实执行Worker 与外部依赖是否就绪。本文基于 testing-workflows.md 展开完整讲解这三层测试的配置、命令与底层实现并深入 WorkflowTestService 等源码帮助你掌握可复现、可定位问题的工作流测试方法论。为什么需要三层测试Conductor 工作流由元数据WorkflowDef、任务Task与 Worker 三部分组成任一环节缺失都会导致执行失败。但校验器无法证明 Worker 已启动Mock 测试无法验证外部端点可达因此必须分层验证Schema 校验检查工作流定义的元数据与图规则任务依赖、输入输出引用、类型合法性不触发任何执行Mock 编排测试用模拟输出替换真实任务结果验证分支、循环、汇聚等编排决策真实执行注册定义、启动工作流、检查终态验证 Worker、消息队列、数据库与 HTTP 端点的真实连通性。前置条件一个可达的 Conductor 服务端本地开发可参考 docker-compose.yaml 启动一份已保存为workflow.json的工作流定义仅最后一层真实执行需要真实的 Worker 与外部依赖。1. 校验工作流定义Schema 校验1.1 校验命令curl -i -X POST http://localhost:8080/api/metadata/workflow/validate \ -H Content-Type: application/json \ --data-binary workflow.json校验成功时返回空的200 OK任何非 200 响应都说明定义存在问题应修复后再注册。1.2 校验的底层实现该接口定义在 MetadataResource.java内部调用metadataService.validateWorkflowDef(workflowDef)。从源码看MetadataServiceImpl.validateWorkflowDef 本身不做显式逻辑——校验由WorkflowDef类上的Valid注解Bean Validation驱动即约束如必填字段、字符串长度、任务引用名唯一性等在请求绑定阶段完成。因此/validate检查的是定义元数据与图规则它无法证明 Worker 正在轮询也无法证明外部端点可达。2. 使用 Mock 任务测试编排逻辑POST /api/workflow/test会执行工作流的决策逻辑任务输出按reference name提供。由于循环或重试可能消耗多个 Mock每个引用名映射到一个列表。2.1 完整的 Mock 测试请求体以下是 workflow-test.json 的完整示例演示了 INLINE 任务含evaluatorType: javascript与对应 Mock{ name: input_param_demo_workflow, version: 1, input: { _scheduledTime: 1760000000000, _executedTime: 1760000000100 }, workflowDef: { name: input_param_demo_workflow, version: 1, schemaVersion: 2, tasks: [ { name: compute_report_window, taskReferenceName: compute_report_window, type: INLINE, inputParameters: { scheduledTime: ${workflow.input._scheduledTime}, executionTime: ${workflow.input._executedTime}, evaluatorType: javascript, expression: ({scheduledAt: $.scheduledTime, triggeredAt: $.executionTime}) } } ], outputParameters: { scheduledAt: ${compute_report_window.output.result.scheduledAt} } }, taskRefToMockOutput: { compute_report_window: [ { status: COMPLETED, output: { result: { scheduledAt: 1760000000000, triggeredAt: 1760000000100 } } } ] } }要点input模拟工作流输入可用workflow.input.xxx引用workflowDef内嵌待测定义无需先注册taskRefToMockOutput为reference name → Mock 列表TaskMock含status默认COMPLETED、output、executionTime毫秒用于模拟超时、queueWaitTime毫秒队列等待时间。其中executionTime与queueWaitTime可触发超时行为用于验证超时重试路径嵌套SUB_WORKFLOW测试使用subWorkflowTestRequestreference name → 另一个WorkflowTestRequest。2.2 发起 Mock 测试curl -sS -X POST http://localhost:8080/api/workflow/test \ -H Content-Type: application/json \ --data-binary workflow-test.json成功结果是任务状态与工作流输出符合预期分支的模拟执行。若任务状态不是终态或taskRefToMockOutput已耗尽则测试无法收敛到预期终态。2.3 底层执行机制源码级解读接口定义在 WorkflowResource.testWorkflow核心实现位于 WorkflowTestService.java防 Worker 抢跑启动测试工作流前request.getTaskToDomain().put(*, domain)用一个随机 UUID 作为 domain确保测试工作流不会被任何真实 Worker 轮询操作符直通operators集合JOIN、DO_WHILE、SET_VARIABLE、FORK、INLINE、TERMINATE、DECISION、DYNAMIC、FORK_JOIN、FORK_JOIN_DYNAMIC、SWITCH、SUB_WORKFLOW不消耗 Mock直接调用decideWorkflow推进Mock 消耗每个 Mock 通过TaskResult回填到对应任务若任务缺失 Mock 且非操作符则runningTasksMissingInput非空、循环提前终止模拟输入缺失子工作流递归对SUB_WORKFLOW类型按subWorkflowTestRequest递归测试子工作流超时模拟当executionTime 0 || queueWaitTime 0时直接改写任务的scheduledTime/startTime并落库以触发超时判定短路保护MAX_LOOPS 20_000防止大循环导致测试失控。3. 运行真实边界测试Mock 测试不接触真实依赖最后必须注册定义并真实启动一次conductor workflow create workflow.json conductor workflow start -w order_workflow -i {orderId:order-123} conductor workflow get-execution workflow-id -c成功标准是工作流达到你预期的终态且任务输出被验证。若SIMPLE任务未注册 TaskDef 且没有轮询 Worker工作流会一直处于排队状态——Mock 测试无法发现这类部署缺口。注意CLI 命令依赖conductor客户端请确保其版本与服务端 API 兼容-w指定工作流名、-i传入 JSON 输入、-c紧凑输出。4. 三层测试的局限与边界Mock 测试不调用 Worker、消息代理、数据库或 HTTP 端点无法验证它们的认证、延迟与重试行为Schema 校验只查定义合法性不证明运行时依赖存在因此每个生产边界都应保留真实的集成测试或冒烟测试。5. 测试与生产环境的衔接结合仓库实践建议将三层测试固化到 CI 流水线提交时运行 Schema 校验curl /validatePR 阶段用 Mock 测试覆盖分支、循环与子工作流决策POST /api/workflow/test部署前在 staging 执行真实冒烟conductor workflow startget-execution。从源码结构看WorkflowTestRequest继承自StartWorkflowRequest因此 Mock 测试天然支持input、taskToDomain等启动参数可在接近生产的输入下验证决策逻辑。延伸阅读为工作流配置可靠性策略Reliability and error handling演练故障恢复Debug and recover工作流定义与创建creating-workflows.md工作流启动方式starting-workflows.md【免费下载链接】conductorConductor is an event driven agentic workflow engine providing durable and highly resilient execution engine for applications and AI Agents项目地址: https://gitcode.com/GitHub_Trending/co/conductor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Conductor 工作流测试与验证实战：Schema 校验、Mock 编排测试与真实执行三层防线
Conductor 工作流测试与验证实战Schema 校验、Mock 编排测试与真实执行三层防线【免费下载链接】conductorConductor is an event driven agentic workflow engine providing durable and highly resilient execution engine for applications and AI Agents项目地址: https://gitcode.com/GitHub_Trending/co/conductor导读在 Conductor 中工作流从定义能跑通到生产可用之间隔着三层验证Schema 校验定义是否正确、Mock 编排测试决策逻辑是否符合预期以及真实执行Worker 与外部依赖是否就绪。本文基于 testing-workflows.md 展开完整讲解这三层测试的配置、命令与底层实现并深入 WorkflowTestService 等源码帮助你掌握可复现、可定位问题的工作流测试方法论。为什么需要三层测试Conductor 工作流由元数据WorkflowDef、任务Task与 Worker 三部分组成任一环节缺失都会导致执行失败。但校验器无法证明 Worker 已启动Mock 测试无法验证外部端点可达因此必须分层验证Schema 校验检查工作流定义的元数据与图规则任务依赖、输入输出引用、类型合法性不触发任何执行Mock 编排测试用模拟输出替换真实任务结果验证分支、循环、汇聚等编排决策真实执行注册定义、启动工作流、检查终态验证 Worker、消息队列、数据库与 HTTP 端点的真实连通性。前置条件一个可达的 Conductor 服务端本地开发可参考 docker-compose.yaml 启动一份已保存为workflow.json的工作流定义仅最后一层真实执行需要真实的 Worker 与外部依赖。1. 校验工作流定义Schema 校验1.1 校验命令curl -i -X POST http://localhost:8080/api/metadata/workflow/validate \ -H Content-Type: application/json \ --data-binary workflow.json校验成功时返回空的200 OK任何非 200 响应都说明定义存在问题应修复后再注册。1.2 校验的底层实现该接口定义在 MetadataResource.java内部调用metadataService.validateWorkflowDef(workflowDef)。从源码看MetadataServiceImpl.validateWorkflowDef 本身不做显式逻辑——校验由WorkflowDef类上的Valid注解Bean Validation驱动即约束如必填字段、字符串长度、任务引用名唯一性等在请求绑定阶段完成。因此/validate检查的是定义元数据与图规则它无法证明 Worker 正在轮询也无法证明外部端点可达。2. 使用 Mock 任务测试编排逻辑POST /api/workflow/test会执行工作流的决策逻辑任务输出按reference name提供。由于循环或重试可能消耗多个 Mock每个引用名映射到一个列表。2.1 完整的 Mock 测试请求体以下是 workflow-test.json 的完整示例演示了 INLINE 任务含evaluatorType: javascript与对应 Mock{ name: input_param_demo_workflow, version: 1, input: { _scheduledTime: 1760000000000, _executedTime: 1760000000100 }, workflowDef: { name: input_param_demo_workflow, version: 1, schemaVersion: 2, tasks: [ { name: compute_report_window, taskReferenceName: compute_report_window, type: INLINE, inputParameters: { scheduledTime: ${workflow.input._scheduledTime}, executionTime: ${workflow.input._executedTime}, evaluatorType: javascript, expression: ({scheduledAt: $.scheduledTime, triggeredAt: $.executionTime}) } } ], outputParameters: { scheduledAt: ${compute_report_window.output.result.scheduledAt} } }, taskRefToMockOutput: { compute_report_window: [ { status: COMPLETED, output: { result: { scheduledAt: 1760000000000, triggeredAt: 1760000000100 } } } ] } }要点input模拟工作流输入可用workflow.input.xxx引用workflowDef内嵌待测定义无需先注册taskRefToMockOutput为reference name → Mock 列表TaskMock含status默认COMPLETED、output、executionTime毫秒用于模拟超时、queueWaitTime毫秒队列等待时间。其中executionTime与queueWaitTime可触发超时行为用于验证超时重试路径嵌套SUB_WORKFLOW测试使用subWorkflowTestRequestreference name → 另一个WorkflowTestRequest。2.2 发起 Mock 测试curl -sS -X POST http://localhost:8080/api/workflow/test \ -H Content-Type: application/json \ --data-binary workflow-test.json成功结果是任务状态与工作流输出符合预期分支的模拟执行。若任务状态不是终态或taskRefToMockOutput已耗尽则测试无法收敛到预期终态。2.3 底层执行机制源码级解读接口定义在 WorkflowResource.testWorkflow核心实现位于 WorkflowTestService.java防 Worker 抢跑启动测试工作流前request.getTaskToDomain().put(*, domain)用一个随机 UUID 作为 domain确保测试工作流不会被任何真实 Worker 轮询操作符直通operators集合JOIN、DO_WHILE、SET_VARIABLE、FORK、INLINE、TERMINATE、DECISION、DYNAMIC、FORK_JOIN、FORK_JOIN_DYNAMIC、SWITCH、SUB_WORKFLOW不消耗 Mock直接调用decideWorkflow推进Mock 消耗每个 Mock 通过TaskResult回填到对应任务若任务缺失 Mock 且非操作符则runningTasksMissingInput非空、循环提前终止模拟输入缺失子工作流递归对SUB_WORKFLOW类型按subWorkflowTestRequest递归测试子工作流超时模拟当executionTime 0 || queueWaitTime 0时直接改写任务的scheduledTime/startTime并落库以触发超时判定短路保护MAX_LOOPS 20_000防止大循环导致测试失控。3. 运行真实边界测试Mock 测试不接触真实依赖最后必须注册定义并真实启动一次conductor workflow create workflow.json conductor workflow start -w order_workflow -i {orderId:order-123} conductor workflow get-execution workflow-id -c成功标准是工作流达到你预期的终态且任务输出被验证。若SIMPLE任务未注册 TaskDef 且没有轮询 Worker工作流会一直处于排队状态——Mock 测试无法发现这类部署缺口。注意CLI 命令依赖conductor客户端请确保其版本与服务端 API 兼容-w指定工作流名、-i传入 JSON 输入、-c紧凑输出。4. 三层测试的局限与边界Mock 测试不调用 Worker、消息代理、数据库或 HTTP 端点无法验证它们的认证、延迟与重试行为Schema 校验只查定义合法性不证明运行时依赖存在因此每个生产边界都应保留真实的集成测试或冒烟测试。5. 测试与生产环境的衔接结合仓库实践建议将三层测试固化到 CI 流水线提交时运行 Schema 校验curl /validatePR 阶段用 Mock 测试覆盖分支、循环与子工作流决策POST /api/workflow/test部署前在 staging 执行真实冒烟conductor workflow startget-execution。从源码结构看WorkflowTestRequest继承自StartWorkflowRequest因此 Mock 测试天然支持input、taskToDomain等启动参数可在接近生产的输入下验证决策逻辑。延伸阅读为工作流配置可靠性策略Reliability and error handling演练故障恢复Debug and recover工作流定义与创建creating-workflows.md工作流启动方式starting-workflows.md【免费下载链接】conductorConductor is an event driven agentic workflow engine providing durable and highly resilient execution engine for applications and AI Agents项目地址: https://gitcode.com/GitHub_Trending/co/conductor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考