Batch Workflow Service
Module
openhcs.pyqt_gui.widgets.shared.services.batch_workflow_service
Purpose
BatchWorkflowService is the single orchestration boundary for:
compile-only batches
execute batches (compile-all first, execute-all after)
execution completion polling
progress projection refresh + server-status emission
Core Types
CompileJob: immutable compile unitBatchWorkflowService: end-to-end compile/execute owner
Dependency Boundary
OpenHCS workflow policy is implemented in BatchWorkflowService. Runtime and
UI polling primitives are consumed as dependencies:
BatchSubmitWaitEngine(fromzmqruntime.execution)ExecutionStatusPoller(fromzmqruntime.execution)IntervalSnapshotPoller(frompyqt_reactive.services)
OpenHCS docs define orchestration policy and host contracts only; generic engine internals are documented in their owning repositories.
Flow: Compile Only
Reset progress views for new batch.
Build
CompileJobentries from selected plates.Submit all jobs then wait all jobs via
BatchSubmitWaitEngine.Write compiled data into
host.plate_compiled_data.Emit orchestrator state transitions and progress updates.
Flow: Run Batch
Reset progress and execution state.
Mark all selected plates queued immediately.
Compile all selected plates before any execution submission.
Submit execution for each plate using
compile_artifact_id.Start per-execution completion pollers.
Converge to completed/failed/cancelled through one callback path.
Host Contract (Expected Attributes/Callbacks)
BatchWorkflowService expects host-owned UI/state callbacks including:
emit_status,emit_error,emit_progress_*update_item_list,update_button_statesemit_orchestrator_state,emit_execution_completeon_plate_completed,on_all_plates_completeddata stores like
plate_compiled_data,plate_execution_states,plate_execution_ids, and_progress_tracker
This is an explicit nominal integration in OpenHCS (not runtime duck-typing).