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

Open
  • Is something wrong?
#327 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
backend, data

Research direction

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.

Written by the indexing model from the issue text.

Description

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.
Dominant language
Python
Stars
186
Forks
79
Avg merge
1h 2m
Merged PRs (30d)
29

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from deepmodeling/Uni-Lab-OS

All issues in deepmodeling/Uni-Lab-OS

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.