Skip to content

真实 HTTPS Webhook 的投递、丢 ACK、重试与恢复验证 #81

Open

Description

@LIghtJUNction

当前范围 · 2026-10-03

剩余收缩为真实HTTPS Webhook接收端的成功/确定失败/丢ACK/重试及恢复验收,保留开放;目标渠道开关与启用后的现场材料归#84。源码已实现的协作原语和通知状态机不再重做。

main 105c2cf7 的CI已验证Domain Event独立capability/撤权/最小引用、request/offer/checkpoint/proposal/handoff/lease/watch及统一EffectJob栅栏;SMTP也有真实TLS socket四种结果。Webhook关键状态当前仍用注入Sink/MockTransport,不能称作公网或真实接收端验收;MSG私有邮箱成功也不能替代该证据。

剩余完成条件

  • 以受控真实HTTPS Webhook接收端验证成功、确定5xx、请求已送达但ACK丢失、重试/恢复,以及TLS/DNS/禁止重定向安全边界;不需要生产任意第三方通知。
  • 核对目标实际SMTP/Webhook开关;未启用保持零外发,启用渠道的目标验收由#84承载,不重复要求全事件笛卡尔矩阵。

本轮依据当前主线 105c2cf716c1179d49bc79224f10f44a3b031163、已完成 CI 和只读部署盘点更新范围。没有执行新的生产迁移、删除、Root/CA 变更或资金操作。旧的全章/全客户端人工矩阵不再作为本项永久门槛。

历史需求与旧验收记录(保留供查阅;当前待办以上述范围为准)

2026-09-28 完成度复核:部分完成,重新打开

本 issue 先前被标为 completed,但正文及最后两条进度评论均明确说明完整验收未完成。本轮按实际范围恢复 open,不撤销已完成切片。

核验基线:main 13c562ea05d273e618b1ea06b9e452da79d4439f;完整 CI 36384948145 success。本轮下载并核验四份产物 SHA-256、分片 manifest 与逐项 JUnit node ID:1,244 core + 8 conformance,零失败/错误/跳过、无遗漏/重复;这是该源码树的回归证据,不是生产投递验收。

已完成,后续必须保留

剩余验收(不删减原范围)

  • 通知偏好、多来源去重、撤权后逐字段裁剪、未配置零外发;真实 SMTP/Webhook 接收端的成功/失败/不确定/重试/恢复矩阵。
  • Domain Event 独立 capability、owner/证书逐次重验;正式事件覆盖与公网 SSRF/DNS/逐跳重定向/私网拒绝、secret 零泄露。
  • request/offer/proposal/receipt/工作 checkpoint/watch 的状态、独立 Revision/Relation/Event、通知及恢复契约;proposal accept 重验当前权限和 revision。
  • handoff/lease 等已归档条款持续回归;协作 lease 不是 worker 租约或排他写锁,不授权限;Sync checkpoint 不冒充工作 checkpoint。
  • 主体路径、CLI、默认、doctor/selftest、PostgreSQL 恢复和完整 CI 对齐。仅用隔离 SMTP sink/受控测试接收端,不隐式启用生产外发。

并行归属与边界

任务 B(市场、存储、通知与协作)主责;任务 C 只负责公共 CLI/Registry 接线与最终串行合并。workers/effects.py、workers/leases.py 的业务改动由 B 维护;任务 A 的恢复隔离接线须交叉审查,不允许覆盖现有租约栅栏。

原设计疑问仍需形成契约:哪些事件可订阅,敏感变化发最小引用还是静默;不同 lease 信任层必须分离。只修切片使用 Refs,不因绿色 CI 自动关闭本总体验收 issue。无生产部署或真实外部通知。

依据:权威设计第 12、15 章 https://docs.google.com/document/d/1EM5Qr5qdg6tAFi2wvY0EBm6zxMj6DTBMc_dybU5qkz0/edit 。

Activity

  1. LIghtJUNction commented on Sep 27, 2026

    @LIghtJUNction
    ContributorAuthor

    本轮已提交并合并的修复:

    #110 正在以更新后的 main 重新验证组合代码及逐测试 ID 的 CI 证据。以上只完成通知重试/完成切片,不把通知偏好、多来源投递、公开 SMTP/Webhook 网络故障矩阵、其余协作原语视为完成。保留本 issue,未进行生产部署或真实外部通知。

  2. LIghtJUNction commented on Sep 27, 2026

    @LIghtJUNction
    ContributorAuthor

    最终组合验证已完成:#110 和 #113 均已合并,当前本轮交付提交为 4c46671。邮件/Webhook 重试和完成现在复用统一的事务内执行轮次/截止时间检查;正常重试次数、退避和渠道错误码不变,过期任务不自动重发。

    完整 CI 36353193024 success:1,109 个测试 + 8 项 conformance 全过,零失败/错误/跳过;产物逐测试 ID 与 SHA-256 已独立核对,合并 tree 与通过测试的 tree 相同。原通知偏好、多来源投递、真实公开 SMTP/Webhook 故障矩阵和其他协作原语未因此视为完成,本 issue 不关闭。没有生产发送或部署。

  3. LIghtJUNction commented on Sep 28, 2026

    @LIghtJUNction
    ContributorAuthor

    已按用户批准的架构收敛提交首个窄补丁 #114(head 2fc4916b6cfc36889d9c5cd0b5972b3d58166720,基于 main acc542a):

    本地 Python 3.13.5 的 58 个新单元用例已通过;另有2个真实应用/PostgreSQL回归进入正常全量CI。目标 Python3.15/PG CI 36392802044 正在运行,尚不标整体完成。代码不修改生产SMTP、金融状态机、schema/短码或其他分支;剩余完整通知/协作验收继续 open。

  4. LIghtJUNction commented on Sep 28, 2026

    @LIghtJUNction
    ContributorAuthor

    新增可复现缺陷切片 #117(不关闭本项):旧地址regex会接收 alias,buyer@example.test 等列表/注释语法,而 SMTP.send_message 默认从头字段重新推导目标,实际收件人可能不等于绑定字符串。已共享core单邮箱校验,在market当前绑定和SMTP最终发送前重验;显式singleton to_addrs,存量/验证邮件任务同样保护。无effects/leases/订单状态机/DDL变更。

    本地 Python3.13.5,真实stdlib邮件解析/序列化+记录型SMTP传输:修复前73 failed/54 passed,修复后127 passed、零跳过,无外发。head 4be8a9d2c9107a3254162e1433b3478f39400fd0,目标完整CI36401618834仍在执行。需求第12/15章和源码security规则已更新;此证据不替代真实SMTP/恢复/完整通知矩阵。

  5. added 2 commits that reference this issue on Sep 28, 2026
  6. LIghtJUNction commented on Sep 28, 2026

    @LIghtJUNction
    ContributorAuthor

    #117 已合并为 072776fa133dc2151edd2b77d89f7813c4c209e2;实际 main tree=ad0a3055f79470a370af680722a78562de6efa23 与最终通过head一致。最终CI36403033365下载核验:1469 core(355/386/386/342)、8 conformance、wheel/sdist,4份SHA-256与真实node-ID互斥全覆盖,零失败/错误/跳过。127新增邮箱回归全部包含在完整目标CI中。

    本次仅完成单邮箱/旧任务/实际SMTP envelope边界,重用#114 EffectJob事实与当前buyer/endpoint绑定,不改变邮件失败对交易无影响的契约。没有真实外部SMTP投递,也没有生产部署;因此#81整体仍open。恢复安全组合继续在#118验证,不以邮件切片完成代替其整体验收。

  7. added 2 commits that reference this issue on Sep 28, 2026
  8. LIghtJUNction commented on Sep 29, 2026

    @LIghtJUNction
    ContributorAuthor

    接续代码修复:v1 lease_list 的无界读取

    已复现并提交修复,GREEN 验收待回收

    当前分支 fix/lease-list-bounds-20260929 head 70d46ce,tree 6fb1502404967778e6e533faf414866557b80a3b。同时保留本切片的 regression-first 历史与 #180 head63bafb4 的分页修复历史;未覆盖主整合分支,也未改 v2 Resource 投影/状态机。

    问题:src/msg/plugins/collaboration.py::lease_list 原 SQL 无 LIMIT,请求 limit 只在 holder 的全部历史租约已经读入内存后生效。当前改成每批最多128行的 keyset 扫描;逐行执行原有当前授权/目标可见性检查;总扫描4096行和真实单调时钟 deadline 限制;超过预算返回精确 query_cost_exceeded。续批使用最后扫描ID,返回的 next_after 仍是最后可见记录ID,不泄露隐藏目标,也不丢掉隐藏批次之后的可见记录。保留 v1 输出与授权语义,不增加缓存授权。

    独立核对的云端 RED

    固定测试提交 fd4cde5 / tree 3a28244429f0e6e5ff3a7bf0fc531ac6411a531e,run 36573737687,artifact 11036112969,ZIP SHA256 84d1745fdd62f383396479358293752bbb9582d5b4073e3b6994110b158b0ffe。已下载并验证 provider 散列、source.json 和真实 JUnit:13 cases / 2 failures / 0 errors / 0 skips。两个失败都明确保存了原来的无 LIMIT SQL,不是泛化 internal_error 或测试环境失败。另11个既有协作回归通过。

    前一次 run36573166697/13项也有两个失败,但 executor 正确隐藏了内部异常细节;因此增加测试端独立 SQL 观察证据后重新复现,没有放宽生产错误脱敏。

    新增回归与边界

    真实PG与签名操作建立目标/租约,然后使用测试专用stress rows覆盖129条已失去可见性的租约跨批扫描、全隐藏、可见/过期/释放投影、连续分页与全表行值/外发不变。额外deadline测试只推进该handler所见的时钟;真实签名、主体、runtime-generation和当前授权不替换,必须在lease SQL前拒绝。

    修复源码 blob f978dc61c866d1c48fab2e3a87979b67d7a8273e,SHA256 ac4247f5629403942506a80c895e4018db4ec56d3a2e279a11a6fedbbef3b74d。仅增加time导入并修改lease_list;handoff等其余实现不变。项目执行全部在云端CI;辅助源码准备只作有散列约束的文本替换/单blob发布,不更新分支,不进入产品树。

    专用 workflow 已随70d46ce推送触发;最终完整分片、conformance/build和适用专项仍需核验。本评论持续更新,不据此关闭 #81/#85 总体验收。无生产、真实外发、Root/PIN或资金操作。

  9. LIghtJUNction commented on Sep 29, 2026

    @LIghtJUNction
    ContributorAuthor

    接续切片:Resource 化协作列表也需有界读取

    固定核对 #181 head70d46cea6dee1fc7bff83f59c0e9c0b3f808c5b6 的 src/msg/plugins/collaboration_resources.py::install_reads/list_records:request/offer/checkpoint/proposal 共用的 SELECT id FROM resources WHERE owner=? AND type=? AND state='active' AND id>? ORDER BY id 没有 LIMIT,全部 owner 记录先物化后才应用请求 limit,也没有独立扫描/deadline预算。这个问题独立于 #181 已修的 legacy lease_list。

    本轮仅接续该文件和定向回归,独立分支,不修改 #180 的并行新提交f304、不取消 #181 的全量36574831146。拟先用真实PG/签名操作复现无LIMIT,再补有界keyset与扫描/截止预算;保留每项Resource/Revision的当前授权、关系裁剪和已有v1接口。进度将在此评论/对应PR记录,不另建总状态副本,不据此关闭#81/#85。

  10. added 2 commits that reference this issue on Sep 29, 2026
  11. LIghtJUNction commented on Sep 29, 2026

    @LIghtJUNction
    ContributorAuthor

    2026-09-29 当前接续(#185 已合并)

    main 5cdaeba2b7b191a27684093cce7b5a153c99c88d / tree 3ad68f2012896310abfa9bcaf800c9ab05f6c886 已实际读回,等于最终PR通过的树。18个PR工作流全部success;8份ZIP摘要/JUnit node-ID独立核验 2531 core + 8 conformance,零失败/错误/跳过。精确来源和产物摘要见 #185证据,更新索引见#83。合并后main push是独立运行,正在核验,不预记成功。

    通知/EffectJob/worker完成fence、SMTP受控socket、Webhook和协作/有界lease等既有回归重新通过;installed worker在未配置mail/Valkey时完成一次运行,external_recipients=0。保持唯一邮箱/SMTP envelope/EffectJob,不把协作lease当worker排他锁或授权来源。真实渠道开关/受控接收端与完整事件条款仍单独验收,没有生产外发。

    各条款源码入口与独立现场材料见 docs/RELEASE_ACCEPTANCE.md。本评论更新证据归属,不降低原验收范围或扩大现场权限。

  12. LIghtJUNction commented on Oct 3, 2026

    @LIghtJUNction
    ContributorAuthor

    剩余收缩为真实HTTPS Webhook接收端的成功/确定失败/丢ACK/重试及恢复验收,保留开放;目标渠道开关与启用后的现场材料归#84。源码已实现的协作原语和通知状态机不再重做。

    main 105c2cf7 的CI已验证Domain Event独立capability/撤权/最小引用、request/offer/checkpoint/proposal/handoff/lease/watch及统一EffectJob栅栏;SMTP也有真实TLS socket四种结果。Webhook关键状态当前仍用注入Sink/MockTransport,不能称作公网或真实接收端验收;MSG私有邮箱成功也不能替代该证据。

  13. changed the title [-][P2] Event/通知/Webhook 与 Agent 协作原语补齐[/-] [+]真实 HTTPS Webhook 的投递、丢 ACK、重试与恢复验证[/+] on Oct 3, 2026
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