Skip to content

fix(lark): keep native topics independent during admission - #6997

Merged
loopx-agent merged 1 commit into
mainfrom
codex/lark-native-topic-dispatch-20261021
Oct 21, 2026
Merged

loopx-agent merged 1 commit into
mainfrom
codex/lark-native-topic-dispatch-20261021

Conversation

@loopx-agent

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

Copy link
Copy Markdown
Collaborator

Goal And Delivered Outcome

Native Bot messages use Core conversation bindings rather than legacy Goal/topic bindings. The stream dispatcher nevertheless tried only legacy routing, putting every native topic in one group on the same unmatched FIFO. Slow source verification for one topic could therefore hold another topic's control message before Core admission.

Derive the transient lane from the existing App-scoped native source normalizer. Different group topics can enter the bounded dispatcher independently; replies in one topic retain FIFO. Private conversations keep their sender-scoped source, and malformed hints retain the conservative fallback. Core admission, grants and source/session fences remain the execution authority.

  • Outcome basis: reproduced runtime defect; base 89bf43de45ab1709961d93913f9add66801fe977.
  • Before → after: the new stream regression fails for both individual and batch records on base, then passes with independent control admission while same-topic follow-up remains queued.
  • Intended base: loopx-project/loopx:main.

Author Declaration

Criterion Disposition Owner / validation
Independent native topics must not wait for another topic's admission implemented _profile_event_lane; real stream dispatch regression, both provider record shapes
One source retains FIFO, including a topic root and its replies implemented Existing lark_private_source identity; ordering regression
Preserve private sender, App and chat isolation implemented Alias/App/chat/sender cases; private roots cannot shard the same sender
Scheduling hints grant no execution implemented Native Core admission retained; malformed hint fallback, existing binding and revocation suite

Scope And Continuation

Complete for native source scheduling in the existing stream. There is no new listener, pool, persistent queue, grant or setting. Legacy routing keeps its current owner. This is an independently testable transport correction; it does not qualify end-to-end provider acknowledgment latency, installed recovery or an entire Bot release. Those require the existing operator acceptance after normal adoption.

Validation

  • Tested revision: 0a9bfdb.
  • Run state: finished.
  • Input classes: synthetic, public_fixture.
Check kind Result Evidence / limitation
Regression before intervention failed as expected Two native-topic cases block on base, demonstrating the defect
Source tests passed 355 related tests, including dispatch, native private delivery and conversation binding/revocation coverage
Required premerge passed Diff/compile/bilingual checks and 10 selected catalog/risk smokes; no failed commands or manual holds
Controlled comparison passed Five bounded samples per arm with a synthetic 350 ms admission hold: unrelated control median wait about 358 ms on base and below 1 ms after the fix; same-source order preserved. This is not provider latency or p95 evidence
CI not queried Managed policy disables CI waiting; local checks and exact-head review remain required
Installed provider journey not yet run Adoption and operator acceptance follow merge; no production SLA claim

Frontend / Visual Evidence

UI impact: none. No layout, text, controls or screenshots changed; this PR fixes the existing Lark stream's transient scheduling.

Type / Area

Bug fix; Lark extension runtime and focused regression coverage.

Boundary Checklist

  • Public-safe code and synthetic fixtures; no private state, credentials, raw traces or local machine paths.
  • Scoped source dispatch correction; no benchmark, permission or storage-authority change.
  • No paired RFC changed; staged and exact-head bilingual validation passed through premerge.
  • UI impact is none.
  • DCO Signed-off-by included.

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; model=gpt-6.1-sol; provider=OpenAI; runtime_reported; reasoning_effort=max.

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

动机

群内同时使用原生 Bot 不同话题的用户会遇到这个阻塞。一个话题受理等待来源读取时,旧路径把另一个话题的停止消息也排在它后面;修复后,两者可在既有有界工作池中独立受理。同群另一个话题的控制消息可独立进入原生受理,原话题追问仍等待前一条受理完成。本次不改变停止、权限或回传语义,也不宣称真实飞书确认时延已经达标。安装后的真实提供方时延、停止执行和原话题回传仍须按既有验收分别核验。

改动思路

只修正已有分发器的来源键,直接复用原生来源正规化器;受理、权限、执行、持久结果及恢复继续由原 Core 和原服务持有。当前 PR 完成原生来源调度的可复现修复;真实提供方时限和整体验收保留在既有运维验收路径。分发器仍是同一个四工作线程、有限容量的传输入口;本次没有增加消息消费者或持久队列。来源键只安排谁可以并行,实际操作仍要由执行时重新读取的原生受理入口核验 App、原消息、授权及会话。维持现状会保留已复现阻塞,单纯增加线程也不能拆开同一条串行通道;复用既有来源正规化器是较小且一致的修复。

具体改动

规范依据是 docs/architecture/rfcs/app-conversation-and-async-inbox-v0.md,固定于 89bf43de45ab1709961d93913f9add66801fe977。本次映射的规范条目为 Selected group topics: isolated ordinary project Chat 和 Ordinary workspace conversations: bounded implementation checkpoint:前者要求同话题共享顺序、不同话题及 App 独立,并保留真实来源授权;后者要求复用单 App 消费者与已有有界、可恢复的受理和回传。两个条目的受影响部分在本提交中均为 implemented,既有 Core 权限与重试部分通过关联回归核验。更广的迁移、上线资格和提供方时限没有被此修复代替。

关键代码讲解

  • _profile_event_lane 先识别当前原生配置,调用既有 lark_private_source 取得不含正文的来源键。群聊以 App、群、话题组合,私聊保留发送者身份;缺失或不合法的提示沿保守回退处理。它没有选取持久 Session 或发出控制操作。
  • poll_lark_goal_topic_profile_once 的执行入口继续使用新快照,把原生消息交给原 private_admitter。调度键与实际执行 owner 因而一致,旧的 Goal 路由没有被当成原生授权。
  • test_native_group_topic_admission_does_not_block_another_topics_control 用没有任何旧 Goal 绑定的快照,真实跑流式拆包和分发;阻塞第一个话题后,检查另一话题控制先进入,而同话题追问仍排队。单条和批量两例在基线都失败,修复后都通过。其余新增案例覆盖同 App 别名、不同 App/群、同话题不同成员、伪造私聊根和坏来源形状。

对主干的风险

主要风险是把不可信事件里的根字段误当成权限,或把实际同源消息拆开导致乱序。复用原有正规化器、私聊忽略伪造根、同群同话题成员共享同键,以及执行时保留原 Core 来源锁,分别覆盖这些边界。四线程与容量限制、异常排空、原监听者重连、撤销和不确定回传均由原 owner 持有;关联测试也覆盖这些未改路径。355 项关联测试与必需 premerge 检查通过,后者执行了 10 项选中 smoke,没有失败或人工 hold。CI 按当前配置未查询。控制实验在两侧使用相同的 350 毫秒合成受理等待;另一话题等待中位数由约 358 毫秒降到 1 毫秒以下。该结果只证明传输排队的隔离,不证明真实飞书时延、原生进程停止或全量发布门槛;安装后的验收仍须保留成功、失败和未跑项。无 UI 布局或截图变化,也没有持久格式迁移。

我的整体评价

结论为 APPROVE,本次是 justified_increment。long_horizon 为 improved:重复受理时一个来源不再阻塞所有原生话题,已有持久恢复和同源顺序保留。user_experience 为 improved:用户沿原消息入口操作,无需新增配置、手工补办或重复确认。代码量与问题匹配,只添加来源选择分支;复用已有 owner 优于新队列、缓存授权或命令专用旁路。语义变化为 local_only 的调度键,现有词汇检查和 Core 权限语义通过验证;其余真实提供方时限与完整发布资格继续留在原验收流程,不能由此 APPROVE 推断完成。当前头为 0a9bfdb3e0cf7bf52402d5830b6730777ed9f359,源码、测试和基线反例已按本头核对,无阻塞性 finding。

English verdict: APPROVE — exact head 0a9bfdb3e0cf7bf52402d5830b6730777ed9f359 fixes reproducible native-topic head-of-line blocking through the existing source normalizer and bounded dispatcher. Both base regressions fail as expected; 355 related tests and required local premerge pass. Core authority and same-source FIFO remain intact. Installed provider latency and full release acceptance remain separate; CI was not queried.

@loopx-agent
loopx-agent merged commit 63728ab into main Oct 21, 2026
19 of 24 checks passed
@loopx-agent
loopx-agent deleted the codex/lark-native-topic-dispatch-20261021 branch October 21, 2026 11:08
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.

1 participant