Proposal: Add optional `threadId` to `retryAttempts` entries

オープン
  • 何か問題がありますか？
#74 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@alexshamrai がすでに取り組んでいます。

2026年10月26日 から。

  • #86 @alexshamrai による — オープン

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
68/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
json
領域
documentation, testing

調査の方向性

Read the Attempt History Entry Object (§11), §9.25, and the schema's retryAttempts.items.properties. Update the specification and schema for the optional per-attempt threadId, including the stated unknown-thread behavior and worker identity guidance. Done when the example and schema reflect the proposal and existing 0.2.0 documents remain valid.

索引モデルが issue の本文から書いたものです。

説明

Problem

Entries in retryAttempts have their own start and stop, but no threadId. The test object's threadId describes the final attempt (§9.3), so a consumer knows when an earlier attempt ran, but not on which thread or worker.

Timeline views need this. Today they have to guess, usually the final attempt's thread, and the guess is often wrong:

Producers can't add it themselves: §11 forbids unknown fields outside extra, and the schema sets additionalProperties: false on attempt items.

Proposal
  1. Add an OPTIONAL threadId (string) to the Attempt History Entry Object (§11): "Identifies the thread or worker on which this attempt executed." Same format as the test object's threadId.
  2. Reword §9.25 to "on which the final attempt executed".
  3. If an attempt entry has no threadId, its thread is unknown; it is not implied to be the test object's threadId. (Inheriting would make every existing report claim that earlier attempts ran on the final attempt's thread.)
  4. Within a document, a threadId value SHOULD identify one worker, so executions that share it ran one at a time. Producers that run tests in several processes or on several hosts SHOULD qualify it, for example fork-2/Test worker.

Schema, in retryAttempts.items.properties:

"threadId": {
  "description": "Thread or worker on which this attempt executed",
  "type": "string"
}

Example: a test that failed on one Gradle fork and passed on retry on another.

{
  "name": "checkout accepts a saved card",
  "status": "passed",
  "duration": 1200,
  "start": 1761200410000,
  "stop": 1761200411200,
  "threadId": "fork-2/Test worker",
  "retries": 1,
  "retryAttempts": [
    {
      "attempt": 1,
      "status": "failed",
      "duration": 1500,
      "start": 1761200400000,
      "stop": 1761200401500,
      "threadId": "fork-1/Test worker"
    }
  ]
}

All of this is additive; every valid 0.2.0 document stays valid.

Context

I ran into this while building a timeline report for github-test-reporter (ctrf-io/github-test-reporter#279). Related: #58 (retry model, settled in #62), #57 and #73 (attempt identity). Happy to open the spec and schema PR.

主要言語
言語のデータがありません
スター
103
フォーク
4
平均マージ
1時間 3分
マージ済み PR（30日）
2

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

ctrf-io/ctrf のほかの issue

ctrf-io/ctrf の issue をすべて見る

似ている issue

Documentation の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。