k2safe/orbit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: recover workflow waits within original deadlines

Browse Source
This commit is contained in:
k2safe
2026-09-18 06:10:04 +08:00
parent 56b9a2ccfe
commit af1ae4cb21
25 changed files with 941 additions and 52 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/16-workflow-recovery.md
View File

@@ -1,15 +1,17 @@
# Weave 人工核查与接续
状态：内部Go服务已提供执行核查、步骤结论确认、解除核查，以及TASK/POLL新激活重试。POLL跨激活预算与附属信号换代见[查询恢复](17-workflow-poll-recovery.md)。公共HTTP、独立SDK和通用接入示例尚未交付；独立SIGNAL/TIMER等待重建继续实现。完整交付继续按[开发计划](08-development-plan.md)推进。
状态：内部Go服务已提供执行核查、步骤结论确认、解除核查，以及TASK/POLL新激活重试。POLL跨激活预算与附属信号换代见[查询恢复](17-workflow-poll-recovery.md)。公共HTTP、独立SDK和通用接入示例尚未交付；[PENDING接续及独立等待重建](18-workflow-wait-recovery.md)已接入内部服务。完整交付继续按[开发计划](08-development-plan.md)推进。
## 1. 四类操作
## 1. 六类操作
[内部服务](../weave/recovery/service.go)要求显式`workflows:recover`权限，普通Worker、任务核查和流程暂停权限均不自动包含它。四个方法都接收认证身份、实例ID、稳定幂等键和命令，命名空间与操作者从认证取得。
[内部服务](../weave/recovery/service.go)要求显式`workflows:recover`权限，普通Worker、任务核查和流程暂停权限均不自动包含它。六个方法都接收认证身份、实例ID、稳定幂等键和命令，命名空间与操作者从认证取得。
| 方法 | 作用 | 不会自动发生的事情 |
| --- | --- | --- |
| ReviewTask | 核实本实例历史激活拥有的NEEDS_REVIEW任务，写入SUCCEEDED/FAILED、明确执行已结束和证据 | 不把查询请求成功解释成业务成功，不解除步骤或实例核查 |
| ResolveStep | 将当前待核查/失败/取消叶子步骤核实为SUCCEEDED或FAILED，保存符合固定契约的逻辑结果 | 不重新执行旧任务，不清除实例核查或原停止意图 |
| ContinuePoll | 根据已处理的权威PENDING结果恢复原等待，保留轮次和间隔 | 不重查同轮，不改写原Inbox处置，不解除实例核查 |
| RearmWait | 在原截止内为独立SIGNAL/TIMER建立新等待代次 | 不延长原截止，不丢弃未消费信号，不重跑成功步骤 |
| Continue | 在当前证据和步骤状态允许时解除实例核查，保存根接续 | 不解除显式paused，不延长截止，不撤销取消或失败结清 |
| RetryStep | 为TASK或POLL建立新的激活和关联任务，继续消耗原任务或原业务轮尝试预算 | 不重跑成功步骤，不改变输入/业务关联，POLL恢复不另起业务轮次 |
@@ -27,7 +29,7 @@
ReviewTask还要求`task_id`、`expected_task_revision`、`execution_settled=true`、SUCCEEDED/FAILED结论和非null JSON结果。声明表示全部历史外部执行已结束且不会继续产生效果；租约失效和UNKNOWN本身不能证明这一点。
ResolveStep和RetryStep都要求固定`step_key`、当前`activation_id`及`expected_step_revision`。前者要求`execution_settled=true`，后者要求`safe_to_retry=true`。Continue要求`review_resolved=true`，服务端仍独立检查当前图、历史任务与来源事件，不把声明作为绕过检查的开关。
ResolveStep和RetryStep都要求固定`step_key`、当前`activation_id`及`expected_step_revision`。前者要求`execution_settled=true`，后者要求`safe_to_retry=true`。ContinuePoll要求`pending_confirmed=true`，RearmWait要求`wait_verified=true`；这两项还要求StepDecision。Continue要求`review_resolved=true`，服务端仍独立检查当前图、历史任务与来源事件，不把声明作为绕过检查的开关。
同键相同命令返回首次冻结回执；同键不同内容冲突。回执恢复仍检查当前凭据和固定定义引用的全部队列权限。后台新增事实使原实例revision失效，新键携带旧版本会冲突；原键可继续核对已提交决定。每个成功人工操作同时递增revision和control_revision，防止旧暂停/继续命令覆盖人工恢复后的控制状态。
@@ -54,7 +56,7 @@ TASK恢复规则如下。要求没有取消或失败停止意图，实例和原
创建新任务后实例仍处于核查，门控保持关闭。操作者确认其他事项已处理后调用Continue，才允许新任务取得执行授权；原paused仍为true时还需正常RESUME。
POLL跨激活恢复已实现，保留原业务轮、同轮剩余尝试、查询总截止和该轮原任务截止；成功返回PENDING的轮次不能人工重查。附属最终信号等待沿用原契约/关联/截止并更换代次，详见[查询恢复](17-workflow-poll-recovery.md)。核查后已确认PENDING的显式等待接续仍需补齐；独立SIGNAL/TIMER逻辑结论可核查，等待重建仍待实现。
POLL跨激活恢复已实现，保留原业务轮、同轮剩余尝试、查询总截止和该轮原任务截止；成功返回PENDING的轮次不能人工重查。附属最终信号等待沿用原契约/关联/截止并更换代次，详见[查询恢复](17-workflow-poll-recovery.md)。核查后已确认PENDING的显式等待接续与独立SIGNAL/TIMER等待重建已实现，见[等待恢复](18-workflow-wait-recovery.md)。
## 5. 停止与到期