Skip to content

fix: bound Lark card text fallback outbound waits#2497

Open
jason-aelf wants to merge 4 commits into
feature/integratefrom
fix/2026-06-30_lark-card-text-fallback
Open

fix: bound Lark card text fallback outbound waits#2497
jason-aelf wants to merge 4 commits into
feature/integratefrom
fix/2026-06-30_lark-card-text-fallback

Conversation

@jason-aelf

Copy link
Copy Markdown
Collaborator

Summary

  • Bound Lark card text fallback outbound waits so card delivery does not wait indefinitely on edit/send failures.
  • Moved shared Lark outbound/card/text edit contracts into the platform Lark abstractions package and wired the concrete tool provider implementation.
  • Added regression coverage for AgentRun Lark card delivery, outbound dispatch, text edit fallback, and scheduled skill-runner reply sinks.

Test Plan

  • bash tools/ci/test_stability_guards.sh
  • dotnet test test/Aevatar.AI.ToolProviders.Lark.Tests/Aevatar.AI.ToolProviders.Lark.Tests.csproj --nologo
  • dotnet test test/Aevatar.GAgents.ChannelRuntime.Tests/Aevatar.GAgents.ChannelRuntime.Tests.csproj --nologo

Notes

  • PR contains commit c96caa6.
  • No merge was performed.

@jason-aelf jason-aelf requested a review from louis4li as a code owner July 1, 2026 02:53
@codecov

codecov Bot commented Jul 1, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.77%. Comparing base (d1ef994) to head (23bc4e2).
⚠️ Report is 19 commits behind head on feature/integrate.

@@                  Coverage Diff                  @@
##           feature/integrate    #2497      +/-   ##
=====================================================
+ Coverage              83.74%   83.77%   +0.03%     
=====================================================
  Files                   1244     1244              
  Lines                  95469    95512      +43     
  Branches               12524    12530       +6     
=====================================================
+ Hits                   79952    80019      +67     
+ Misses                  9954     9930      -24     
  Partials                5563     5563              
Flag Coverage Δ
ci 83.77% <ø> (+0.03%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 6 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@louis4li

louis4li commented Jul 1, 2026

Copy link
Copy Markdown
Contributor

我看了一下,这个 PR 方向是在解决正确的问题,但当前实现明显偏重,建议先收敛后再合。

目标可以更简单地表达为:

  1. Lark 收到 workflow 请求后,先快速回一条普通文本,例如“正在处理”;
  2. workflow 最终结果出来后,优先 best-effort 编辑第一条文本;
  3. 如果没有编辑权限、编辑失败或 edit port 不可用,就直接发送新的普通文本;
  4. 长内容按普通文本分段发送;
  5. CardKit 只能是可选的 rich renderer,不能成为首条可见回复或最终结果投递的依赖。

当前 PR 的主要问题是:

  • 实现仍然围绕 LarkCardTextFallback,看起来是在 card 创建失败后才进入文本 fallback;但用户问题是 workflow 等很久没有反馈,所以首条普通文本应该在 workflow accepted / durable handoff 时就发出,而不是等 card 路径失败或超时。
  • 改动面过大:新增/迁移 Lark platform abstractions、proxy response、error codes、edit port、docs 和大量测试。这里有些抽象可能有独立价值,但不应该和这个窄修复绑在一个 PR 里。
  • 引入了过重的 fallback 状态机和持久状态:phase、segment count、last delivered text、error fields、fallback changed event、timeout/update/retry 等。这些更像 transport delivery telemetry,不应该成为 AgentRun 的核心 domain state。这个需求最多需要持久化第一条 text message id / correlation,以及最终文本是否完成投递。
  • edit 不应该是硬依赖。正确语义是 edit 成功就编辑第一条,edit 不可用或失败就发新文本;不能因为缺少 card/edit 权限导致普通文本最终结果也失败。

建议改成最小实现:

Lark message received
  -> workflow/run accepted or durable handoff
  -> send ordinary text: 正在处理...
  -> store message id if available

workflow final text ready
  -> split by Lark plain-text limit
  -> try edit first processing message with first segment
  -> if edit unavailable/fails, send first segment as new text
  -> send remaining segments as ordinary text
  -> CardKit optional only

建议本 PR 收敛为上述普通文本主路径;Platform.Lark.Abstractions 迁移如果确实需要,建议拆成独立 PR,否则当前 review/回归面过大。

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