Skip to content

proposal(runtime): abandon uncertain execution suffix and fork fresh Turns from the safe prefix #5671

Description

@likun666661
English

Problem

After startup recovery seals a dispatched tool call without a durable result, its external effect may already have happened. The old execution cannot be safely resumed or silently retried. PR #5657 permits an explicit new client message, but projects a synthetic outcome_unknown response and system notice so the incomplete old branch remains in model history.

Proposed semantics

Use the first unresolvable execution boundary as a fork point. For future model context, abandon the entire old suffix at and after that boundary, including later durable facts on the abandoned branch. Start an explicitly submitted new Turn from the last trustworthy prefix plus the new user message. Do not synthesize a tool result, continue the old Turn, or automatically re-dispatch any old tool call.

This is a model-context and execution-lineage decision, not deletion or rollback. Preserve all canonical events in the ledger for audit, diagnostics, and user-facing inspection. An external effect of an abandoned call may still have occurred. The new Turn might independently choose a similar action; this proposal neither claims exactly-once effects nor treats dropped history as an undone effect.

Later Turns must follow the new branch, never accidentally reintroducing the abandoned suffix because the ledger is linear. Continuation, handoff, and maintenance requiring settled history retain strict safety boundaries; they must not infer that the abandoned events settled.

Why consider this

The causal rule is unresolvable boundary -> abandon suffix for model input -> explicit new user Turn from safe prefix. It avoids manufacturing a model-visible result for an event that never settled and carrying special unknown-result reconciliation through subsequent requests. Durable facts and the ban on automatic replay remain intact.

Acceptance criteria

  • The old execution remains nonresumable and its unknown tool is never automatically retried.
  • A fresh client message starts a new Turn from the trustworthy prefix; the abandoned suffix is absent from every subsequent model request.
  • No synthetic ToolSettled is written and no synthetic outcome_unknown tool response is needed in the new model branch.
  • Original events remain inspectable in the ledger/UI, with the abandoned branch distinguishable from the active branch; external effects are not represented as rolled back or failed.
  • A second restart and later Turns preserve the fork boundary and do not resurrect the abandoned suffix.
  • Tests cover multiple calls in one model output, a settled call followed by an unknown call, later durable facts in the abandoned branch, and maintenance/continuation/handoff boundaries.

Scope

This proposes alternative semantics to #5657, not historical-event rewriting or relaxed side-effect safety. Choose the precise active-branch representation after checking existing context selection, checkpoints, and lineage contracts.

AI assistance disclosure

Codex assisted with analysis and drafting.

简体中文

问题

启动恢复后,旧执行可能留下“工具已发出、结果未持久化”的记录。副作用可能已经发生,因此不能恢复旧执行或静默重试。#5657 允许显式的新客户端消息继续,但仍通过临时 outcome_unknown 响应和 system notice 把旧的半完成分支带入模型历史。

建议语义

以第一个无法确定的执行边界为分叉点:对后续模型上下文放弃该边界及其之后的整个旧分支,包括之后恰好已经持久化的事实。从此前可信的前缀加上新的用户消息开启新 Turn。不合成工具结果,不续跑旧 Turn,也不自动重新发出旧工具调用。

这只改变模型上下文和执行 lineage,不删除 ledger,也不回滚外部副作用。原始事件仍供审计、诊断和用户查看。被放弃工具的外部效果可能已经发生;新 Turn 也可能独立决定执行类似动作,本提案不承诺 exactly-once。

后续新 Turn 沿新分支继续,不能因为 ledger 是线性的就重新带入被放弃的后缀。Continuation、handoff 和要求完整结算历史的维护操作仍保留严格安全边界。

验收标准

  • 结果未知的旧执行不可恢复,旧工具不会自动重试。
  • 显式新消息从可信前缀开启新 Turn;旧分支后缀在以后所有模型请求中均不可见。
  • 不写入假的 ToolSettled,新分支不需要临时 outcome_unknown 工具响应。
  • 原始事件在 ledger/UI 中仍可检查,新旧分支可区分;不暗示外部副作用已回滚或失败。
  • 再次重启及后续多个 Turn 不会重新带入被放弃的后缀。
  • 测试覆盖同一模型输出中的多个工具调用、已结算调用后接未知调用、旧分支后续持久化事件,以及维护/continuation/handoff 边界。

范围

本 issue 讨论替代 #5657 的语义,不要求改写历史事件或放宽副作用安全。活动分支的具体表示,待核对现有上下文选择、checkpoint 和 lineage 契约后确定。

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions