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

Abierto
  • ¿Algo no está bien?
#74 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@alexshamrai ya está trabajando en esto.

Desde el 26/10/2026.

  • #86 de @alexshamrai — abierto

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
68/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
json
Área
documentation, testing

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Sin datos de lenguaje
Estrellas
103
Forks
4
Merge medio
1 h 3 min
PR fusionados (30 d)
2

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ctrf-io/ctrf

Todos los issues de ctrf-io/ctrf

Issues similares

Más issues de Documentation

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.