Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Timeline: draw earlier retry attempts on the thread that ran them (retryAttempts[].threadId)

Đang mở
  • Có gì không ổn?
#334 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
55/100
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
node.js, typescript
Lĩnh vực
data-visualization, testing

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

  1. Read the field. In readTests, read attempt.threadId with 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.
  2. 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 through placeAttempts() and can end up in "Runs before a retry".
  3. 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.
  4. 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 maxLanes check include threads that appear only in attempt history.
  5. Types. The ctrf package (0.5.0) types AttemptHistoryEntry without threadId and validates against spec 0.2.0. Until it ships spec 0.3.0, read the field through a narrow cast; then bump ctrf and drop the cast. Merging already keeps the field, because mergeReports copies tests as they are, but it can't validate such reports against 0.2.0, so the merged specVersion falls back to the inputs' version.
  6. Docs and sample. Mention attempt threadId in the timeline section of docs/report-showcase.md, and give the retried test in ctrf-reports/timeline/ctrf-report.json an 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 ctrf npm release with spec 0.3.0, for the types.
  • Reporters that fill in retryAttempts[].threadId. Until they do, the timeline stays as it is.
Ngôn ngữ chính
TypeScript
Star
380
Fork
43
Merge trung bình
3 ngày 11 giờ
Pull request đã merge (30 ngày)
2

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của ctrf-io/github-test-reporter

Tất cả issue của ctrf-io/github-test-reporter

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.