Define merge semantics for `results.errors`
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 25/100
- Issue 类型
- 功能
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 技术栈
- typescript
- 领域
- tooling
调研方向
Start with the spec text that #88 adds for results.errors, then read src/merge.ts in ctrf-cli and in ctrf-js to see how the first shard's fields are kept. The issue first asks for a spec rule (concatenate every input's errors, in input order, with no de-duplication), which needs maintainer agreement before any code. Done means the spec wording is agreed and both merge functions keep every shard's errors, with tests for multi-shard input.
由索引模型根据 Issue 内容生成。
描述
Follow-up to #65, from this comment. Builds on #88, which adds results.errors: [{message, trace, extra}].
Problem
Sharded runs are routinely merged into one CTRF document. Merging is where run-level errors get lost. #88 says nothing about merging. Current CTRF tooling would silently drop errors from every shard but the first:
ctrf mergein ctrf-cli keepsextraandenvironmentfrom the first shard only.- ctrf-js
merge()keeps the first value for each key and rebuilds the result without anyresults.errorshandling.
So aAshard that failed in global teardown would produce a merged report with no error and, if all its tests passed, a green verdict.
Precedent
Tools that merge run-level errors concatenate them:
- Playwright's
merge-reportsreplays every shard'sonErrorwith no de-duplication. It merges run status worst-first: failed, then timedout, then interrupted, then passed. - Allure 3 appends errors without de-duplication.
De-duplication is also risky: the same message from two shards (for example, "Database cleanup failed") might mean two separate failures.
Proposal
Add to the spec:
When merging CTRF documents (for example, shards of one run),
results.errorsSHOULD be the concatenation of every input document'sresults.errors, in input order, without de-duplication. A merging tool MAY record the source document or shard in each entry'sextra.
Then update ctrf merge and ctrf-js merge() to follow it.
Related
If an optional run outcome is added (separate issue), its merge rule should follow Playwright's worst-first ordering.
- 主要语言
- 没有语言数据
- 星标
- 103
- 派生
- 4
- 平均合并
- 1 小时 3 分钟
- 30 天内合并 PR
- 2
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
ctrf-io/ctrf 的其他 Issue
-
难度 1/5 1 小时以内 新手友好度 76/100
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 18/100
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 15/100
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 20/100
维护者通常 1 天内回复
-
Proposal: Add optional `threadId` to `retryAttempts` entries可能已有人在做 @alexshamrai 于 12 天前认领。 未关闭
难度 3/5 1-2 天 新手友好度 68/100
维护者通常 1 天内回复
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
eliasstravik/herdr-projects#787 ·
-
难度 2/5 1-3 小时 新手友好度 78/100
code-yeongyu/oh-my-openagent#12784 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
-
难度 2/5 1-3 小时 新手友好度 82/100
-
难度 2/5 1-3 小时 新手友好度 71/100
btclib-org/btclib#2964 ·
维护者通常 1 天内回复