【建议】停止后的 generation 缺少统一终止状态与结果隔离机制

[Nyanniee]

关联说明

本 issue 与 #733（优化流式响应异常处理：避免无条件 rollback，并开放 retry 行为配置）相关，但讨论的是不同层面的问题：

• 【建议】优化流式响应异常处理：避免无条件 rollback，并开放 retry 行为配置 #733 讨论的是「决定不再重试时，是否应该保留已经生成的内容」。
• 本 issue 讨论的是「用户主动点击停止后，本次 generation 是否能够被可靠终止，以及后续迟到返回的数据是否仍可能影响 UI 或历史记录」。

如果 #733 的建议被采纳，用户可以主动关闭自动重试，从而减少部分相关场景的触发概率。但即使关闭 retry，本 issue 关注的「取消后的 generation 生命周期管理」问题仍然独立存在。

问题描述

实际观察到的场景：

1. 首轮流式回复输出到一半，内容突然消失，界面提示报错并进入自动重试。
2. 用户在这个过程中点击了「停止」。
3. 界面显示为「已停止」状态，但过了一段时间后仍然开始继续流式输出。
4. 输出结束后，内容又整体消失。
5. 部分情况下可以观察到额外的请求消耗。

核心诉求可以概括为：

用户点击停止后，当前 generation 应进入一个明确的终止状态；此后即使存在已经发出但延迟返回的数据，也不应再影响当前 UI 状态或写入历史记录。

代码层面的排查情况

查看 ClaudeProvider 中 cancelStreaming() 的实现：

override fun cancelStreaming() {
    isManuallyCancelled = true

    activeResponse?.let {
        try {
            it.close()
        } catch (e: Exception) { ... }
    }
    activeResponse = null

    activeCall?.let {
        if (!it.isCanceled()) {
            it.cancel()
        }
    }
    activeCall = null
}

以及重试循环：

while (retryCount <= maxRetries) {
    if (isManuallyCancelled) {
        throw UserCancellationException(...)
    }
    val call = try {
        ...
        client.newCall(request)
    }
    ...
}

进一步核对后，可以确认：

• 重试循环在发起下一次请求之前会检查 isManuallyCancelled，因此最初关于「delay 结束后完全不检查取消状态，直接继续发起 retry」的推测并不成立，这一点需要更正。
• retry 流程与原始请求处于同一个 stream { ... } 协程结构内，但当前取消方式主要依赖 @Volatile 状态标志位和取消具体的 Call 对象，而不是通过结构化并发方式取消整个 generation 生命周期。
• 当前未观察到针对单次 generation / request 的独立生命周期标识或结果校验机制，用于判断某个返回的数据是否仍属于当前有效的生成过程。

因此，更准确的问题描述不是「停止一定无法阻止 retry」，而是：

当前实现缺少一个能够覆盖完整 generation 生命周期的终止与结果隔离机制。

如果某个请求在取消信号生效前已经进入网络层，或者某些异步结果在取消后才返回，目前没有看到一个独立的机制能够保证这些结果一定会被识别为「已失效 generation 的结果」并安全丢弃。

与其他客户端的对照

例如 RikkaHub 的停止实现：

suspend fun stopGeneration(conversationId: Uuid) {
    val job = sessions[conversationId]?.getJob() ?: return
    job.cancel()
    runCatching { job.join() }
    finishInterruptedPendingTools(conversationId)
}

这里取消的是整个任务生命周期，而不仅仅是某一次网络调用对象。

这种设计的核心区别在于：

• 取消请求中的网络操作；
• 取消等待中的 retry / suspend 状态；
• 确保取消完成后，不再允许该任务继续提交结果。

这类生命周期级取消机制，可以作为 Operit 当前实现的参考方向。

建议

这里的建议有明确主次：

1. 首要建议：让「停止」作用于整个 generation 生命周期

当前停止逻辑主要针对当前 Call 对象。

建议考虑让停止操作能够取消包裹整个生成流程的任务生命周期，而不是只取消当前网络请求。

这样可以同时覆盖：

• 正在进行中的请求；
• retry 等待阶段；
• 后续可能产生的继续处理逻辑。

具体实现方式可以由维护者根据当前架构决定，例如协程 Job 取消、任务 token、取消状态传播等。

2. 增加取消后的结果隔离机制作为兜底

即使请求取消无法在所有网络时序下做到绝对及时，也应该保证：

• 已经失效的 generation 返回的数据不会继续展示；
• 不会写入当前对话历史；
• 不会覆盖新的生成状态。

实现方式不限定，可以是 generation id、request token、状态校验等生命周期标识机制。

需要注意的是：

仅增加结果过滤只能解决「错误结果继续影响客户端状态」的问题，无法解决请求已经发出后的资源消耗。因此结果隔离应作为生命周期取消机制的补充，而不是替代。

已知的不确定性

• 当前无法确认观察到的「停止后仍继续输出」现象具体对应代码中的哪一个执行路径。
• 目前没有找到确定性的代码证据证明某一条固定路径必然导致该现象，因此本 issue 主要提出生命周期管理上的缺口和需要确认的保护机制。
• 已发出的网络请求是否能够被完全终止，与具体协议、连接方式以及上游服务行为有关，需要结合当前网络层实现评估。

修改范围

预计涉及：

• 停止操作与 generation 生命周期之间的状态管理。
• retry、stream、response 处理流程中的取消传播。
• 取消后的结果校验与历史写入保护。

具体实现方式由维护者根据现有架构评估。

环境

该问题在通过第三方反代 / 网关接入模型、上游响应延迟较高的情况下更容易观察到，因为「请求已经进入网络层但结果尚未返回」的时间窗口会被放大。

但问题本质并不依赖具体上游服务，而是：

用户的「停止」操作，是否能够可靠约束一个 generation 从开始到结束的完整生命周期。

[Nyanniee]

补充：继续沿着停止调用链排查，发现一个值得进一步确认的点

继续追踪「停止」操作的调用链后，又发现一个值得进一步确认的实现细节，补充在这里供参考。

真正的停止入口 cancelMessageInternal（MessageProcessingDelegate.kt）：

private suspend fun cancelMessageInternal(chatId: String, keepPartialResponse: Boolean) {
    ...
    val jobsToCancel =
        linkedSetOf<Job>().apply {
            chatRuntime.sendJob?.let { add(it) }
            chatRuntime.stateCollectionJob?.let { add(it) }
            chatRuntime.streamCollectionJob?.let { add(it) }
        }

    AIMessageManager.cancelOperation(chatId)

    jobsToCancel.forEach { job -> job.cancel() }
    jobsToCancel.forEach { job ->
        try {
            job.join()
        } catch (_: CancellationException) { }
    }
    ...
}

这里可以看到，sendJob 等协程都会执行规范的 cancel() + join()，调用方会等待这些 Job 真正结束后再继续执行。

继续追踪 AIMessageManager.cancelOperation(chatId)：

activeEnhancedAiServiceByChatId.remove(chatKey)?.let {
    it.cancelConversation()
}

fun cancelConversation() {
    invalidateAllExecutionContexts("cancelConversation")

    initScope.launch {
        runCatching {
            multiServiceManager.cancelAllStreaming()
        }
        ...
    }
}

multiServiceManager.cancelAllStreaming() 最终会进入各 Provider 的 cancelStreaming()；以 ClaudeProvider 为例，这里会执行 activeCall.cancel()、activeResponse.close() 等网络层取消操作。

不过这里采用的是 initScope.launch { ... } 异步派发，cancelConversation() 本身不会等待这部分逻辑执行完成。

因此，从调用方角度来看：

• cancelMessageInternal() 返回时，可以确认 sendJob 等协程已经结束；
• 但无法确认底层网络取消是否已经执行完成，或者是否已经传播到 Provider。

这一点未必就是导致本 issue 所描述现象的原因，目前也没有足够证据证明两者存在直接因果关系。

不过它意味着当前停止流程中，不同层面对「取消完成」的定义并不完全一致：上层等待的是 Job 生命周期结束，而底层网络取消则通过另一条异步路径继续执行。

这一实现未必意味着存在问题，也可能是经过设计权衡后的选择。例如，异步派发本身可能是为了避免将网络层取消过程直接阻塞到调用方；如果确实如此，我更关心的是：当前是否还有其他机制，能够在调用方视角建立一个明确的「停止已经完成」语义——例如保证网络层取消已经完成，或者保证取消之后迟到返回的数据不会再影响当前 generation。

如果已有这样的保护机制，那么大概率是我还没有继续追踪到对应代码；如果没有，那么这里或许值得进一步讨论。