重试轨迹里的attempt编号重复，怎样核对父子关系和实际派发

一次业务的日志里出现两个相同attempt编号，不能直接把记录行数当成真实派发数。它可能是重复采集，也可能是两次发送被错误写成同一个身份。本文定义自己的轨迹字段，检查唯一性、父子关系和串行成功后的新增派发，不再用重试层数推测上游次数。

先把业务节点、控制器和派发叶节点分开

附件中b1是业务根，s1是SDK控制器，u1和u2是上游派发节点。每项都带business、id、parent、kind与seq；派发节点另带outcome。id在本份轨迹内唯一，父节点必须存在并先出现，业务归属必须相同。这里的字段名和顺序都是本地合同，不是OpenTelemetry导出格式，也不构成任何链路追踪认证。

正常轨迹有四个节点，却只有u1、u2两次派发。u1失败、u2成功，控制器与业务根不计入发送。若用日志总行数统计，会把结构记录也算进去；若先用字典覆盖重复id，又会悄悄丢失冲突证据。因此附件先检查原始数组中的重复，再建立索引，最后按序号审查关系。

四种反例分别给出可解释原因

第一种把u2改成u1，必须报告duplicate，不能猜两条是否属于同一次。第二种让叶节点指向absent，报告missing-parent。第三种把叶节点business换成另一个业务，但父节点仍在b1中，报告cross-business。三项错误都应阻止该轨迹用于准确派发统计，不能一边标坏数据一边继续给出确定次数。

第四种在u2成功后添加u3。本文明确是串行控制器，成功后没有尚未开始的新尝试，因此报告after-success。若真实系统采用并发竞速，成功后收到另一项已在途结果不一定违规；应另带派发与完成时刻，不能把“完成较晚”偷换成“成功后才派发”。本夹具没有测试这种并发生命周期。

把轨迹统计与实际发送证据对齐

当前运行器实际遍历数组，检查父类必须为业务到控制器、控制器到上游两层，并数出两个叶节点，四个负例均被拒绝。它验证的是一份合成轨迹的内部完整性，没有发送HTTP请求，也不能证明真实服务没有漏记某次发送。OpenTelemetry资料用于理解父子追踪概念，协议是否允许重试与轨迹数据是否完整仍是不同问题。

接入网关时，建议在真正派发入口生成稳定尝试身份，把该身份与发送计数关联；采集侧保留原始冲突项，不要静默去重修复。序号的生成范围、进程重启后的唯一性和跨服务归属还要按实现补验。先让轨迹能回答“这条叶节点属于哪次业务、由谁触发、是否已成功短路”，再计算次数，才能避免错误日志给出貌似精确的结论。

配套样本与复核入口

下载本篇独立合成输入和实验运行器。上述文件放在同一目录后运行 python run_lab.py C001。完整运行需要全部四十四份输入及相关配置。结果中的method区分离线计算、静态参考检查与回环实测，不能把前两者当成真实网关已通过。

补充文件：c001-attempt-tree.json。合成表供独立复算，配置片段是否实跑以正文说明为准。

资料核对日期：2026-10-24。官方依据1；官方依据2。

与本站相关基础教程的区别：旧文已讲嵌套放大；新题专审本地轨迹关系完整性和串行成功后的派发，字段是本文合同，不冒充OpenTelemetry格式认证。