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

Aperta
  • Qualcosa non va?
#74 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@alexshamrai ci sta già lavorando.

Dal 26/10/2026.

  • #86 di @alexshamrai — aperta

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
68/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
json
Ambito
documentation, testing

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Nessun dato sulla lingua
Stelle
103
Fork
4
Merge medio
1h 3m
PR unite (30g)
2

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ctrf-io/ctrf

Tutte le issue di ctrf-io/ctrf

Issue simili

Altre issue su Documentation

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.