Adjuntos de resultado de ejecución

Durante una ejecución, un miembro puede registrar un resultado actual por paso (texto libre) y adjuntos de imagen opcionales (PNG, JPEG o WebP). El flujo es análogo al de adjuntos de paso de caso: las imágenes se procesan en servidor a WebP (tamaño completo, borde más largo ≤ 2048px, conservando proporción) y se genera una miniatura (≤ 320px), siguiendo el patrón stage-and-commit.

El acceso requiere rol member o superior en el proyecto de la ejecución. Las operaciones de escritura (stage, commit, delete) se permiten en una ejecución open o en una ejecución cerrada sin abortar cuando la configuración de ejecución allowResultsInClosedRuns del proyecto (ver Configuración de ejecución) resuelve a true (el valor por defecto del código); una organización o proyecto que lo fije en false las rechaza con 409 en una ejecución closed. Una ejecución aborted siempre rechaza las escrituras con 409, sin importar el valor de esta configuración. Las lecturas siempre están permitidas.

Flujo

1. Stage — POST /api/v1/runs/{runUlid}/cases/{runCaseUlid}/steps/{stepUlid}/result-attachments:stage con multipart/form-data y una o más partes file. Escribe en staging/<orgUlid>/ y devuelve referencias en estado staged (sin fila aún).
2. Commit — PATCH /api/v1/runs/{runUlid}/cases/{runCaseUlid}/steps/{stepUlid}/result con el texto actualResult y los refs en attachments[]. El servidor copia staged → claves permanentes (attachments/<orgUlid>/<projectUlid>/run-steps/<runCaseStepUlid>/<attUlid>.webp), inserta filas, borra los objetos staged y persiste el texto.
3. Lectura — GET /api/v1/runs/{runUlid}/cases/{runCaseUlid} devuelve actualResult y attachments[] por paso (ordenado por position). Las miniaturas se sirven en GET /__assets/{thumbKey}.

Los objetos staged abandonados expiran automáticamente mediante la regla de ciclo de vida de R2 (~48 h).

Stage (multipart)

curl -sS -X POST \
  -H "Authorization: Bearer $PROBARA_API_TOKEN" \
  -F "file=@captura.png" \
  "https://app.probara.net/api/v1/runs/$RUN/cases/$RC/steps/$ST/result-attachments:stage"

200 devuelve la misma forma que adjuntos de paso (StagedRunResultAttachmentRef).

Commit (PATCH result)

{
  "actualResult": "Apareció HTTP 500 en lugar del dashboard",
  "attachments": [
    {
      "ulid": "01J...ATT",
      "position": 0,
      "objectKey": "staging/01J...ORG/01J...UPLOAD.webp",
      "thumbKey": "staging/01J...ORG/01J...UPLOAD_thumb.webp",
      "mime": "image/webp",
      "byteSize": 8420,
      "width": 1200,
      "height": 800,
      "originalFilename": "captura.png"
    }
  ]
}

La reconciliación funciona exactamente igual que con adjuntos de paso: los ulids nuevos se promueven, los existentes se conservan (solo se actualiza position), y cualquier ulid ya almacenado que se omita del payload se borra (filas + R2 permanente + contador de almacenamiento).

El servidor no confía en los valores byteSize, width ni height enviados por el cliente al hacer commit — los re-mide leyendo R2. Los refs staged cuyo prefijo de clave no coincida con la organización del solicitante se rechazan (guardia cross-tenant).

actualResult: null limpia el texto; omitirlo deja el valor anterior intacto. Omitir attachments deja el conjunto comprometido sin tocar.

Borrar un adjunto

curl -sS -X DELETE \
  -H "Authorization: Bearer $PROBARA_API_TOKEN" \
  "https://app.probara.net/api/v1/runs/$RUN/cases/$RC/steps/$ST/result-attachments/$ATT"

204 en éxito. 404 cuando el adjunto no existe o pertenece a otra organización. 409 cuando la ejecución está cerrada y allowResultsInClosedRuns resuelve a false, o la ejecución está abortada (siempre).

Operaciones sobre un caso de la ejecución

El tablero de ejecución rediseñado añade dos operaciones a nivel de caso:

• POST /api/v1/runs/{runUlid}/cases/{runCaseUlid}/retry — reinicia el caso (y los snapshots de sus pasos) a untested y recalcula el agregado. Emite run.case_retried.
• DELETE /api/v1/runs/{runUlid}/cases/{runCaseUlid} — quita el caso (cascada: pasos + adjuntos de resultado) y recalcula el agregado. Emite run.case_removed.

Ambas siguen la misma regla de ejecución cerrada que el resto de esta página: permitidas en una ejecución open o cerrada sin abortar cuando allowResultsInClosedRuns resuelve a true (el valor por defecto del código); 409 en una ejecución closed solo cuando esa configuración es false, y siempre 409 en una ejecución aborted.

Contabilidad de almacenamiento

Los bytes de adjuntos de resultado comprometidos (completo + miniatura) incrementan organization_storage_usage para la categoría run_result_attachment. Los bytes en staging no se contabilizan. El contador es la base para los futuros planes de precios.

Relacionado

• Adjuntos de paso de caso — homólogo en autoría
• Configuración de ejecución — allowResultsInClosedRuns y el resto del vocabulario de configuraciones de ejecución
• Referencia interactiva v1 — esquemas completos