Releases: ContactEngineering/muflow
Releases · ContactEngineering/muflow
Release list
v0.4.0
v0.3.0
- Fixed critical caching bug:
manifest.jsonis now only written on successful task completion, ensuring that failed tasks can be safely retried. - Dedicated error state: Added a new
error.jsonmarker file written upon task failure, capturing the error message, traceback, and apartial_manifestof files written prior to failure.
v0.2.0
Breaking changes
- Renamed "workflow" to "task" across the entire codebase (
Workflow->Task,@register_workflow->@register_task, etc.). - Removed
TaskContextProtocol. UseTaskContextdirectly instead. - Caching moved to execution time:
Pipeline.build_plan()no longer accepts anis_cachedcallback. Cache detection now happens automatically insideexecute_task()— ifmanifest.jsonalready exists at the task's storage prefix, the task is skipped without re-running. Remove anyis_cached=...arguments frombuild_plan()calls and anyLocalStorageBackend.make_cache_checker()/is_result_cached()usage. TaskNode.cachedfield removed. Tasks are no longer pre-marked cached at plan-build time.run_plan_locally()no longer accepts ause_cacheparameter. Caching is always active and requires no configuration.LocalStorageBackend.make_cache_checker()andLocalStorageBackend.is_result_cached()removed.ExecutionResultgains a newcached: boolfield (defaultFalse) indicating whether the task was skipped due to an existing result.ExecutionResult.files_writtenremoved. Tasks communicate results exclusively through file writes to the storage context.submit_plan()now returnsPlanHandleinstead of a rawstr. Update any code that stores or inspects the return value directly.on_node_start,on_node_complete, andon_node_failureremoved from theExecutionBackendprotocol. They remain as keyword-only parameters onLocalBackend.submit_plan()for testing and CLI use.CompletionCallback.notify()signature changed from(analysis_id: int, result: ExecutionResult)to(plan_id: str, success: bool, error: Optional[str]). Update any custom callback implementations.
New features
save_text/read_text:StorageBackend,LocalStorageBackend,S3StorageBackend, andTaskContextnow exposesave_text(filename, data, encoding="utf-8")for writing plain-text files, complementing the existingsave_file(bytes),save_json, andsave_xarray.TaskContextalso addsread_text(filename, encoding="utf-8")as a convenience wrapper. This closes the gap withOutputFile(file_type="text"), which had no corresponding write method.open_filewrite-mode guard:open_fileis read-only by design. BothLocalStorageBackendandS3StorageBackendnow raiseValueErrorif a write mode (w,a, orx) is passed. PreviouslyLocalStorageBackendsilently opened the file for writing while bypassing write-once semantics,allowed_outputschecks, and manifest tracking;S3StorageBackendsilently discarded the write and returned a read buffer instead.PlanHandle: serializable reference to a submitted plan execution. Callhandle.to_json()to store it (e.g. in a Django model field) andPlanHandle.from_json(s)to restore it later. Methods:get_state() -> str—"pending"|"running"|"success"|"failure". For Celery hits Redis; for Step Functions callsdescribe_execution; never queries S3.get_progress() -> PlanProgress— per-node completion based onmanifest.jsonpresence.cancel()— revokes the Celery chord or stops the Step Functions execution.configure_celery(app)— class-level method; call once at startup soget_state()/cancel()work outside theCeleryBackendinstance.
PlanProgress: returned byPlanHandle.get_progress(). Fields:total,completed,node_breakdown: dict[str, bool]. Properties:fraction(0.0–1.0),is_complete.ProgressCheckerprotocol (muflow.storage): storage-layer abstraction for checking node completion across multiple prefixes without querying an execution backend.LocalProgressChecker: checksos.path.exists(prefix/manifest.json).S3ProgressChecker(bucket): oneHEADrequest per prefix (10–50 ms each within the same AWS region).make_progress_checker(storage_type, storage_config): factory that reconstructs the right implementation from serialized config; extend by adding a new class and one branch here.
CeleryCompletionCallbackwired intoCeleryBackend: passcompletion_callback=CeleryCompletionCallback(app, "myapp.tasks.on_complete")tosubmit_plan()and amuflow.send_completionCelery task fires after the plan finishes, calling your task with(plan_id, success, error). Themuflow.send_completiontask is registered automatically bycreate_celery_task().
v0.1.0
Initial release.
Features
- Workflow registry:
@register_workflowdecorator for registering pure
workflow functions with optional Pydantic parameter validation - Pipeline abstraction:
Pipeline,Step, andForEachfor declarative
multi-step DAG definitions - WorkflowPlan: Static, serializable DAG representation compiled from
pipelines via topological sort - Content-addressed storage: Deterministic prefix computation with
IdentityKeyannotations for cache control - WorkflowContext: Unified file I/O interface (JSON, xarray, raw bytes)
with dependency access and progress reporting
Execution backends
- LocalBackend: Synchronous in-process execution for testing and CLI use
- CeleryBackend: Parallel DAG execution via Celery chord/group primitives
- StepFunctionsBackend: AWS Step Functions orchestration with Lambda
Storage backends
- LocalStorageBackend: Filesystem-based storage with write-once semantics
and path traversal protection - S3StorageBackend: AWS S3 storage backend
Utilities
run_plan_locally()helper for pipeline integration testingResourceManagerandresolve_urifor transparent local/remote resource
fetching- Extended JSON encoder with NaN, numpy, and datetime support
- xarray Dataset serialization helpers