[Feature Request] Standardize execution receipts, state transitions, and artifact lineage

Abierto
  • ¿Algo no está bien?
#327 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
backend, data

Línea de trabajo

Start by reading unilabos/ros/device_node_wrapper.py:36-40, unilabos/devices/hplc/AgilentHPLC.py:124-226, and the executor paths at unilabos/devices/workstation/workflow_executors.py:245-279 and :454-470. Compare their result handling with the existing Task/Job restart and recovery model. Done means a versioned common receipt covers the listed states, lineage, failures, and recovery cases, with tests for partial execution, timeout, retry, missing artifacts, and success.

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

Descripción

Problem

Execution results do not have a common receipt linking requested parameters, resolved resources, device acknowledgements, telemetry, raw files, parsers, and derived results.

Concrete code evidence

  • unilabos/ros/device_node_wrapper.py:36-40 forwards device method calls but exposes no common run/attempt/artifact receipt.
  • unilabos/devices/hplc/AgilentHPLC.py:124-226 has device-specific start_sequence, check_status, and get_data_file methods with a local result shape.
  • unilabos/devices/workstation/workflow_executors.py:245-279 reduces workflow execution to boolean success/failure in one executor path.
  • unilabos/devices/workstation/workflow_executors.py:454-470 similarly collapses a liquid transfer result into a boolean.

Design gap

The current return values cannot consistently distinguish:

command accepted
execution started
execution completed
measurement acquired
raw artifact saved
artifact parsed
QC passed

They also do not provide a uniform lineage from sample/method/resource to raw and derived data.

Proposed receipt

Define a versioned receipt containing:

  • run and attempt IDs;
  • method and capability versions;
  • requested parameters and resolved bindings;
  • resource snapshot and reservation/claim IDs;
  • state transitions and timestamps;
  • device acknowledgements and telemetry references;
  • raw artifact paths, media types, and checksums;
  • parser/analysis job versions and result references;
  • typed failure, blocked, unsupported, and human-confirmation outcomes.

Acceptance criteria

  • Every protocol run can emit a common receipt without device-specific fields being required.
  • Receipts distinguish planning, execution, measurement, artifact, parsing, QC, failure, and recovery states.
  • Raw artifacts are immutable references with sample/method/run lineage and checksums.
  • Receipts integrate with the existing Task/Job restart and recovery model.
  • Tests cover partial execution, timeout, retry, missing artifact, and successful completion.
Lenguaje dominante
Python
Estrellas
181
Forks
78
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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 deepmodeling/Uni-Lab-OS

Todos los issues de deepmodeling/Uni-Lab-OS

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.