Timeline: draw earlier retry attempts on the thread that ran them (retryAttempts[].threadId)
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 55/100
- Issue 类型
- 功能
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- node.js, typescript
调研方向
Start with src/ctrf/timeline/collect.ts, especially readTests, arrange() and placeAttempts(), then review the timeline notes in src/ctrf/timeline/report.ts. Check the timeline tests and sample at ctrf-reports/timeline/ctrf-report.json; the issue does not name specific test files. Done when attempts with recorded threadId appear on their recorded worker, missing IDs retain current placement, and the docs and sample reflect the change.
由索引模型根据 Issue 内容生成。
描述
Summary
CTRF 0.3.0 adds an optional threadId to attempt history entries (retryAttempts[].threadId), so each earlier attempt can record the thread or worker that ran it. The Test-level threadId now explicitly describes the final attempt. See ctrf-io/ctrf#74 and ctrf-io/ctrf#86, part of the 0.3.0 release tracked in ctrf-io/ctrf#75.
The timeline report (#279) should use it to draw each earlier attempt on the thread that actually ran it, and keep today's placement only for attempts that don't record a thread.
How it works today
Earlier attempts don't record a thread, so readTests gives every attempt its test's threadId, which is the thread of the final attempt (collect.ts#L353-L372). arrange() packs each thread's final results, and placeAttempts() tries to fit each earlier attempt into a gap on the first four lanes of that thread (collect.ts#L908, collect.ts#L1019). Attempts that fit nowhere go to a separate "Runs before a retry" lane, with a note that such runs do not record where they ran (report.ts#L748-L751).
When a retry runs on a different worker than the failed attempt, that guess is wrong in one of two ways:
- The attempt fits a gap on the final attempt's thread. It is drawn on a worker that never ran it, and nothing in the chart says so.
- It doesn't fit. It moves to the "Runs before a retry" lane, and the worker that actually ran it shows an idle gap at that time.
Either way, the tests drawn next to the failed attempt are the wrong neighbours. That matters most when looking for order-dependent or shared-state flakiness.
Proposed change
- Read the field. In
readTests, readattempt.threadIdwith the same normalization as the test's (normalizeThreadId) and keep it on the attempt. An attempt without one inherits its test's thread, as today, and is marked as inherited. - Place recorded attempts like final results. In
arrange(), put attempts with a recorded thread into that thread's group and pack them together with its final results. Only inherited attempts go throughplaceAttempts()and can end up in "Runs before a retry". - Keep overlap handling. The spec doesn't guarantee that a worker runs one test at a time, since some frameworks run tests concurrently within a worker. A recorded attempt that overlaps other tests on its thread splits the thread into extra lanes, as final results already do, instead of being moved out.
- Update the counts and notes. The stray-attempt note counts only attempts without a recorded thread, for which its wording stays true. Thread counts and the
maxLanescheck include threads that appear only in attempt history. - Types. The
ctrfpackage (0.5.0) typesAttemptHistoryEntrywithoutthreadIdand validates against spec 0.2.0. Until it ships spec 0.3.0, read the field through a narrow cast; then bumpctrfand drop the cast. Merging already keeps the field, becausemergeReportscopies tests as they are, but it can't validate such reports against 0.2.0, so the mergedspecVersionfalls back to the inputs' version. - Docs and sample. Mention attempt
threadIdin the timeline section ofdocs/report-showcase.md, and give the retried test inctrf-reports/timeline/ctrf-report.jsonan attempt on another worker.
Reports without attempt threadId render exactly as they do now.
How it improves the timeline
- Each earlier attempt is drawn on the worker that ran it, so per-worker busy and idle time is accurate.
- A failed attempt is shown next to the tests that really ran beside it on its worker. That is where order-dependent and shared-state flakiness shows up.
- A retry that moved to another worker is visible as such: the failed attempt on one row, the final attempt on another.
- A worker whose only results are failed attempts, such as one replaced after a failure, gets its own row. Today it doesn't appear.
- The "Runs before a retry" lane and its note remain only for reports that don't record attempt threads.
Dependencies
- ctrf-io/ctrf#86: the spec change, in the 0.3.0 stack (ctrf-io/ctrf#75).
- A
ctrfnpm release with spec 0.3.0, for the types. - Reporters that fill in
retryAttempts[].threadId. Until they do, the timeline stays as it is.
- 主要语言
- TypeScript
- 星标
- 380
- 派生
- 43
- 平均合并
- 3 天 11 小时
- 30 天内合并 PR
- 2
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
ctrf-io/github-test-reporter 的其他 Issue
-
难度 3/5 1-2 天 新手友好度 55/100
ctrf-io/github-test-reporter#309 · 1 条评论 ·
-
Excessive memory usage when processing history leads to Javascript Heap Exhaustion可能重新可做 @HenrikDK 于 121 天前认领,目前没有进行中的 PR。 未关闭
难度 4/5 3-5 天 新手友好度 48/100
ctrf-io/github-test-reporter#302 · 2 条评论 ·
-
难度 3/5 1-2 天 新手友好度 65/100
ctrf-io/github-test-reporter#297 · 1 条评论 ·
-
难度 5/5 一周以上 新手友好度 45/100
ctrf-io/github-test-reporter#282 ·
-
难度 3/5 1-2 天 新手友好度 48/100
ctrf-io/github-test-reporter#258 · 1 条评论 ·
查看 ctrf-io/github-test-reporter 的全部 Issue
相似的 Issue
-
bug
难度 1/5 1 小时以内 新手友好度 86/100
awslabs/visual-asset-management-system#937 ·
维护者通常 1 天内回复
-
t0ggles
难度 1/5 1 小时以内 新手友好度 82/100
nolimits4web/swiper#8255 · 1 条评论 ·
维护者通常 15 天内回复
-
render: --variables-file (and --variables <path>) fails with "io.readFile is not a function" since 0.8.212可能已有人在做 @miguel-heygen 今天认领。 未关闭bug triage/needs-triage
难度 2/5 1-3 小时 新手友好度 76/100
heygen-com/hyperframes#6830 ·
维护者通常 1 天内回复
-
bug launch local use
难度 2/5 1-3 小时 新手友好度 65/100
维护者通常 1 天内回复
-
account: profile bug
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 5 天内回复