Conductor 如何用 Signal API 恢复等待中的 WAIT 任务【免费下载链接】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 工作流执行到WAIT任务时会停在原地等待外部系统审批人、第三方回调、定时判断等给出决定。此时你手上通常只有 workflow ID没有 task ID也不打算轮询。Conductor 的 Signal API 就是为这种情况设计的只凭 workflow ID把工作流中第一个未结束的WAIT任务按你指定的状态和输出数据解决掉工作流随即继续执行。前提是一个 Conductor 服务器已在运行REST API 可通过http://localhost:8080访问本文所有示例均与文档保持一致。准备条件一个已注册、包含WAIT任务的工作流定义一次已经启动、并且恰好阻塞在该WAIT任务上的工作流执行即已拿到 workflow ID要写入的决定结果例如审批通过/拒绝以及附加字段。下面用一个文档中的订单审批例子走完整条路径。第一步注册一个包含 WAIT 任务的工作流工作流定义只有一个任务收到orderId后进入等待直到外部信号到来。信号传入的整个 payload 会成为该WAIT任务的输出并通过outputParameters中的表达式${approval.output}映射为工作流输出。{ name: order_approval, description: Wait for an external order approval signal, version: 1, schemaVersion: 2, inputParameters: [orderId], tasks: [ { name: wait_for_approval, taskReferenceName: approval, type: WAIT } ], outputParameters: { orderId: ${workflow.input.orderId}, approval: ${approval.output} } }通过 metadata API 注册把上面的 JSON 保存为order_approval.jsoncurl -X POST http://localhost:8080/api/metadata/workflow \ -H Content-Type: application/json \ -d order_approval.json第二步启动工作流并确认它已阻塞在 WAIT 任务上使用同步执行端点启动工作流。该端点会启动工作流并等到终态或遇到阻塞的WAIT任务才返回waitForSeconds默认10waitUntilTaskRef可用于让某个特定任务引用也结束等待。curl -X POST http://localhost:8080/api/workflow/execute/order_approval/1?requestIdapproval-demo-42waitForSeconds30returnStrategyBLOCKING_TASK_INPUT \ -H Content-Type: application/json \ -d {input:{orderId:order-42}}returnStrategy决定响应返回哪个对象值返回内容TARGET_WORKFLOW按 ID 请求的工作流默认值BLOCKING_WORKFLOW包含当前阻塞点的工作流可能是子工作流BLOCKING_TASK当前阻塞的任务BLOCKING_TASK_INPUT当前阻塞任务的输入响应中的 workflow ID 就是后续 Signal 调用要用的目标。第三步用 Signal API 恢复被阻塞的 WAIT 任务Signal 端点有两个变体路径中的workflow-id替换为第二步拿到的 workflow IDURL 路径里的状态字段COMPLETED、FAILED等决定这次决定被记录成什么请求体就是写入的 payload。异步版本调用方只需提交决定服务端解决当前阻塞的WAIT任务后立即返回不在响应中给出工作流状态。curl -X POST http://localhost:8080/api/tasks/workflow-id/COMPLETED/signal \ -H Content-Type: application/json \ -d {approved:true,approvedBy:managerexample.com,reason:Within policy}同步版本调用方需要在同一个响应里拿到工作流的新状态时使用。它接受与执行端点相同的returnStrategy取值并最多等待timeoutMillis默认5000毫秒。curl -X POST http://localhost:8080/api/tasks/workflow-id/COMPLETED/signal/sync?returnStrategyTARGET_WORKFLOWtimeoutMillis5000 \ -H Content-Type: application/json \ -d {approved:true,approvedBy:managerexample.com}同步版本的响应语义如果工作流之后又进入另一个WAIT任务响应表示那个新的阻塞状态如果先完成响应表示已完成的工作流。如果此时并没有可 signal 的阻塞任务同步路由返回404而异步路由提交后即返回不提供这一状态判断。验证恢复结果本例中WAIT任务被COMPLETED解决后没有后续任务工作流应进入完成状态。用 Workflow API 按 ID 查询curl http://localhost:8080/api/workflow/workflow-id判断点均来自本文定义中的字段约定顶层status应为COMPLETED状态取值包括RUNNING、PAUSED、COMPLETED、FAILED、TIMED_OUT、TERMINATEDoutput.approval中应包含 signal 时提交的 payload 字段例如approved、approvedBy、reason——因为 signal 的 payload 被存为WAIT任务的输出并经outputParameters映射出来若工作流在WAIT之后还有任务它们可以${approval.output.approved}、${approval.output.reason}这类表达式引用 signal 写入的数据。拒绝或让失败路径执行如果决定是拒绝且希望走工作流的失败路径把 URL 中的状态换成FAILED即可无需其他改动curl -X POST http://localhost:8080/api/tasks/workflow-id/FAILED/signal \ -H Content-Type: application/json \ -d {reason:Order exceeds the approval limit}边界与替代路径Signal 不做精确寻址。它固定作用于工作流中含正在运行的子工作流第一个未结束的WAIT任务不能指定任意taskReferenceName也不解决HUMAN任务signal 不会启动新的执行。只有在解决当前阻塞等待正是你想要的语义时才用这个端点。需要精确指定任务时改用按引用名更新任务的端点POST /api/tasks/{workflowId}/{taskRefName}/{status}请求体同样是输出数据 JSON map其同步变体POST /api/tasks/{workflowId}/{taskRefName}/{status}/sync会直接返回更新后的完整工作流对象。404 的含义不同。同步 Signal 的404表示没有可 signal 的阻塞任务工作流可能已完成或已不在等待而按引用名更新任务时404表示找不到对应taskRefName的运行中任务。遇到404时先用GET /api/workflow/{workflowId}查看当前状态和任务列表再判断。参考文档Sending signals to workflowssignal 行为、同步/异步端点与returnStrategy的完整说明Wait and timer patternsWAIT任务的固定延迟、定时与外部信号三种模式Task API按引用名更新任务POST /api/tasks/{workflowId}/{taskRefName}/{status}等端点Start Workflow API 与 Workflow API同步执行端点参数、查询工作流状态【免费下载链接】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 如何用 Signal API 恢复等待中的 WAIT 任务
Conductor 如何用 Signal API 恢复等待中的 WAIT 任务【免费下载链接】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 工作流执行到WAIT任务时会停在原地等待外部系统审批人、第三方回调、定时判断等给出决定。此时你手上通常只有 workflow ID没有 task ID也不打算轮询。Conductor 的 Signal API 就是为这种情况设计的只凭 workflow ID把工作流中第一个未结束的WAIT任务按你指定的状态和输出数据解决掉工作流随即继续执行。前提是一个 Conductor 服务器已在运行REST API 可通过http://localhost:8080访问本文所有示例均与文档保持一致。准备条件一个已注册、包含WAIT任务的工作流定义一次已经启动、并且恰好阻塞在该WAIT任务上的工作流执行即已拿到 workflow ID要写入的决定结果例如审批通过/拒绝以及附加字段。下面用一个文档中的订单审批例子走完整条路径。第一步注册一个包含 WAIT 任务的工作流工作流定义只有一个任务收到orderId后进入等待直到外部信号到来。信号传入的整个 payload 会成为该WAIT任务的输出并通过outputParameters中的表达式${approval.output}映射为工作流输出。{ name: order_approval, description: Wait for an external order approval signal, version: 1, schemaVersion: 2, inputParameters: [orderId], tasks: [ { name: wait_for_approval, taskReferenceName: approval, type: WAIT } ], outputParameters: { orderId: ${workflow.input.orderId}, approval: ${approval.output} } }通过 metadata API 注册把上面的 JSON 保存为order_approval.jsoncurl -X POST http://localhost:8080/api/metadata/workflow \ -H Content-Type: application/json \ -d order_approval.json第二步启动工作流并确认它已阻塞在 WAIT 任务上使用同步执行端点启动工作流。该端点会启动工作流并等到终态或遇到阻塞的WAIT任务才返回waitForSeconds默认10waitUntilTaskRef可用于让某个特定任务引用也结束等待。curl -X POST http://localhost:8080/api/workflow/execute/order_approval/1?requestIdapproval-demo-42waitForSeconds30returnStrategyBLOCKING_TASK_INPUT \ -H Content-Type: application/json \ -d {input:{orderId:order-42}}returnStrategy决定响应返回哪个对象值返回内容TARGET_WORKFLOW按 ID 请求的工作流默认值BLOCKING_WORKFLOW包含当前阻塞点的工作流可能是子工作流BLOCKING_TASK当前阻塞的任务BLOCKING_TASK_INPUT当前阻塞任务的输入响应中的 workflow ID 就是后续 Signal 调用要用的目标。第三步用 Signal API 恢复被阻塞的 WAIT 任务Signal 端点有两个变体路径中的workflow-id替换为第二步拿到的 workflow IDURL 路径里的状态字段COMPLETED、FAILED等决定这次决定被记录成什么请求体就是写入的 payload。异步版本调用方只需提交决定服务端解决当前阻塞的WAIT任务后立即返回不在响应中给出工作流状态。curl -X POST http://localhost:8080/api/tasks/workflow-id/COMPLETED/signal \ -H Content-Type: application/json \ -d {approved:true,approvedBy:managerexample.com,reason:Within policy}同步版本调用方需要在同一个响应里拿到工作流的新状态时使用。它接受与执行端点相同的returnStrategy取值并最多等待timeoutMillis默认5000毫秒。curl -X POST http://localhost:8080/api/tasks/workflow-id/COMPLETED/signal/sync?returnStrategyTARGET_WORKFLOWtimeoutMillis5000 \ -H Content-Type: application/json \ -d {approved:true,approvedBy:managerexample.com}同步版本的响应语义如果工作流之后又进入另一个WAIT任务响应表示那个新的阻塞状态如果先完成响应表示已完成的工作流。如果此时并没有可 signal 的阻塞任务同步路由返回404而异步路由提交后即返回不提供这一状态判断。验证恢复结果本例中WAIT任务被COMPLETED解决后没有后续任务工作流应进入完成状态。用 Workflow API 按 ID 查询curl http://localhost:8080/api/workflow/workflow-id判断点均来自本文定义中的字段约定顶层status应为COMPLETED状态取值包括RUNNING、PAUSED、COMPLETED、FAILED、TIMED_OUT、TERMINATEDoutput.approval中应包含 signal 时提交的 payload 字段例如approved、approvedBy、reason——因为 signal 的 payload 被存为WAIT任务的输出并经outputParameters映射出来若工作流在WAIT之后还有任务它们可以${approval.output.approved}、${approval.output.reason}这类表达式引用 signal 写入的数据。拒绝或让失败路径执行如果决定是拒绝且希望走工作流的失败路径把 URL 中的状态换成FAILED即可无需其他改动curl -X POST http://localhost:8080/api/tasks/workflow-id/FAILED/signal \ -H Content-Type: application/json \ -d {reason:Order exceeds the approval limit}边界与替代路径Signal 不做精确寻址。它固定作用于工作流中含正在运行的子工作流第一个未结束的WAIT任务不能指定任意taskReferenceName也不解决HUMAN任务signal 不会启动新的执行。只有在解决当前阻塞等待正是你想要的语义时才用这个端点。需要精确指定任务时改用按引用名更新任务的端点POST /api/tasks/{workflowId}/{taskRefName}/{status}请求体同样是输出数据 JSON map其同步变体POST /api/tasks/{workflowId}/{taskRefName}/{status}/sync会直接返回更新后的完整工作流对象。404 的含义不同。同步 Signal 的404表示没有可 signal 的阻塞任务工作流可能已完成或已不在等待而按引用名更新任务时404表示找不到对应taskRefName的运行中任务。遇到404时先用GET /api/workflow/{workflowId}查看当前状态和任务列表再判断。参考文档Sending signals to workflowssignal 行为、同步/异步端点与returnStrategy的完整说明Wait and timer patternsWAIT任务的固定延迟、定时与外部信号三种模式Task API按引用名更新任务POST /api/tasks/{workflowId}/{taskRefName}/{status}等端点Start Workflow API 与 Workflow API同步执行端点参数、查询工作流状态【免费下载链接】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），仅供参考