Skip to content

fix(lark): retain recovery fairness across discovery backoff - #6914

Merged
huangruiteng merged 1 commit into
mainfrom
codex/bot-recovery-fairness-20261020
Oct 19, 2026
Merged

huangruiteng merged 1 commit into
mainfrom
codex/bot-recovery-fairness-20261020

Conversation

@loopx-agent

@loopx-agent loopx-agent commented Oct 19, 2026 •

Copy link
Copy Markdown
Collaborator

The original reply worker can starve a later durable request when recovery discovery temporarily omits candidates during backoff. It discarded fairness counts on those hint gaps, so the same earlier unresolved requests could repeatedly consume all available slots.

Keep the existing per-request count while its durable journal exists. This changes scheduling hints only: the original worker, four-slot/no-executor-backlog limit, source/permission/native-effect gates, queue and result journal are unchanged. No new consumer, model invocation, replay policy, timer or persistent state is added.

The new controlled worker test presents five unchanged durable requests over three discovery windows separated by empty hint windows. The immutable baseline never reaches the fifth request; the changed original worker reaches all five and preserves the four-slot limit. 280 related source cases,106 installed selected cases and all6 direct/11 selected exact-head premerge checks pass; the installed production Python/TypeScript files are byte-verified against the reviewed source. Actual original-source execution and returns remain post-install acceptance; this fix does not establish provider health or overall reply SLA.

Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>

@loopx-agent loopx-agent left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewer: model_agent; gpt-6.1-sol; OpenAI; runtime_reported; effort=max; active_turn_verified=false

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

动机

受影响的是等待 Bot 自动接续的用户:同一队列里,后面的原请求可能一直没有机会进入处理。五条规范请求都还在,但发现器在退避期间暂时返回空列表。旧 worker 清掉尝试计数,下一次又让前四条占满空位;修改后保留计数,第五条在下一轮获得机会。受控测试中,原 worker 跨三轮发现能覆盖全部五条请求,每轮最多仍是四项;原始文件与消费者数量不变。本 PR 只修已有回复 worker 的公平调度,不修 provider 路由、重试准入、模型执行或业务结果,不新增消费者、计时器或持久队列。真实 provider 健康、具体请求能否执行成功以及完整回传时延仍需独立线上验收;公平地获得一次机会不等于业务完成。这次验收关注后面的请求是否真正进入原处理函数,而不是只检查发现列表有无变化或展示一个等待状态。

改动思路

发现列表是瞬时提示,规范工作是否还存在应看原持久 journal;用提示缺席退役公平计数会把两种事实混在一起。本 PR 仅把已有公平计数的退役条件改为原 journal 实际消失,保留原四槽并发、无执行积压及全部准入/回传拥有者。继续用已有 attempted 计数和原 pool,计数只在实际提交后增加;规范文件仍在,某轮退避就保留计数。它不保存待执行内容,也不声明请求已经准备好、获得授权或完成。比新建重试服务或改变等待秒数更直接。

最强反对理由是,保留已见 journal 的计数会增加少量内存和存在性检查,直到记录移除或服务结束。这里的数量受既有持久 journal 数和原 worker 生命周期限制,仍只决定先后;没有额外执行积压,代价与避免长期饥饿相称。若需改变整个 journal 的保留策略,应由原存储拥有者处理,不在本次增加第二套生命周期。

具体改动

依据 docs/architecture/rfcs/app-conversation-and-async-inbox-v0.md,修订 4810c4b8b6fca99f625558ccf76212d663aeebba。existing-worker 保留原扫描器和会话队列;fenced-admission 保留当前 App/本人/grant、来源及完整原生凭证核验;original-result 保留原失败、确定性预留和原消息回传。新增双语段落说明发现退避的公平性条件,不能用该新段落自证旧实现正确。

关键代码讲解

  1. _reconcile_private 原来按本轮 paths 删除计数,现在按实际 journal 是否存在保留计数。最少尝试优先、四槽 pending 上限、原 reconcile_request 调用和停止条件均未改变。
  2. pending_delivery_paths 的既有退避会暂时隐藏 delivered recovery 候选,因此空列表不能证明规范请求已退出。它仍只是发现提示;实际工作继续经过 Core 与来源 fence,未增加授权分支。
  3. 新测试给原循环五个保留文件,三轮完整发现之间插入空窗口。完成态 Future 只控制执行完成时机,公平选择仍执行真实 worker 代码。旧基线第五项从未进入处理;当前版全部五项被调用,第二轮包含之前跳过的第五项,每轮不超过四项,文件内容与消费者数量保持。真实线程池的无积压、停止和唤醒路径另由已有测试覆盖。

四文件56增/1删,生产改动为一个条件与注释,43行用于可复现的正反例,余下是双语说明。没有引入状态协议、CLI、消费者、配额或调度配置;现有同来源重复/失败/权限处理仍在原拥有者中。

对主干的风险

本地计数不保证 provider 健康或模型成功,文件消失也只删除公平提示,不能据此把业务标为完成。不能把这个改动与此前原生未执行失败的续办准入混为一条新重试策略。已检查相关6855的返回事务重构范围,没有重复修改当前 worker 的公平调度。

280项相关源测试、106项实际安装包选择测试通过;关键生产 Python/TypeScript 字节与当前源一致。精确提交的6项直接、11项选中 premerge 检查和 Ruff 均通过。相同新断言在不可变基线上失败,确切差异是第五项未进入原处理函数。既有真实 pool/停止与授权/未知效果/失败回传用例继续通过。测试没有模拟“业务完成”来充当实际执行证据,线上结果另验。

语义与 CI 对齐

使用规范 journal 存在性与已有尝试计数,不按文案分类、不新增全局状态或强制义务。默认变化、保留范围和失败边界已在两份 RFC 与 PR 描述披露。当前矩阵 wait_for_ci=false,未查询或等待远端 CI。

我的整体评价

未发现阻塞项,结论 APPROVE,范围 e902e44e387e8d966c44e3ec7c23bb07136acda5。长期执行(long_horizon)的改善是原请求不会因为临时提示消失而不断丢掉排队历史;用户体验(user_experience)的改善是后面的消息也能获得已有工作流的处理机会,无需本人再次催办或维护者人工派发。这个增量修复实际默认路径,保留 provider/模型仍可能失败及真实回传仍需核验的边界,没有把公平调度冒充全部业务修复。

English verdict: APPROVE for e902e44e387e8d966c44e3ec7c23bb07136acda5. The original bounded worker now retains its existing fairness history across transient discovery gaps, keyed by durable journal presence. The immutable-base counterexample and source/package checks establish the scheduling correction; unchanged effect gates remain authoritative and live provider/business outcomes are separate.

@huangruiteng
huangruiteng merged commit e3c25b4 into main Oct 19, 2026
10 of 32 checks passed
@huangruiteng
huangruiteng deleted the codex/bot-recovery-fairness-20261020 branch October 19, 2026 19:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants