AetherFlow
In development · M08A Rust-based distributed workflow execution platform focused on durable state, recoverable workers, reliable delivery, and observability. It remains under active development and is not production-ready.
Distributed workflows face process crashes, network partitions, and duplicate delivery. The hard problem is not merely queuing work: state must be recoverable and transitions auditable.
The Rust and Tokio core is organized around durable state, recoverable workers, and explicit execution semantics. PostgreSQL provides durable storage and NATS JetStream provides event transport.
Maintained in the public Pooya Labs organization; the current README does not identify an individual author or contribution split.
An asynchronous Rust/Tokio core and Axum control plane sit over durable PostgreSQL and NATS JetStream. Outbox/Inbox supports at-least-once delivery; Wasmtime, a CLI, typed Rust SDK, OpenAPI, and OpenTelemetry provide extension and operations layers.
- 01Durable workflow/task lifecycles, auditable events, and transactional aggregation.
- 02Recoverable workers with leases, heartbeats, epoch fencing, and bounded retries.
- 03Versioned workflow/task/worker/tenant API; ten tables with FORCE RLS.
- 04Separate migration/runtime roles and operator/tenant credentials.
- 05JSON logs, correlated tracing, bounded metrics, and opt-in OTLP.
- 01The guarantee is at-least-once, not universal exactly-once; external effects need application-level idempotency.
- 02The project remains experimental; Compose and CI are not production hosting.
- 03Benchmarks compare only matching fingerprints and are not production SLOs.
- 04RPO/RTO, PITR/WAL archiving, and more operational drills remain open.
- 01M00–M07 are complete; M08 remains in progress.
- 02Restore-to-runtime passed in run 41882781118 and API restart recovery passed in run 42011508896.
- 03Two five-repeat EPYC 9V45 sessions reconciled 896 events per workload with zero duplicates/errors.
- 04In-flight worker/API outage, additional failure injections, and final-SHA comparator verification remain open.
- 01At-least-once delivery paired with idempotent execution primitives
- 02Worker recovery through leases, heartbeats, and bounded retries
- 03Explicit cancellation, timeout, concurrency, and backpressure semantics
- 04Versioned API, OpenAPI, structured logs, metrics, and tracing
- 05Operational backup/restore and recovery drills
M00–M07 are complete and M08 is in progress. The project remains experimental; benchmark and recovery tests are not production SLOs or proof of production readiness, and universal exactly-once execution is not claimed.