iroddis

Thanks for the feedback. I'll take a look at how Luigi models task state. Right now each TaskExecutor type is responsible for running and reporting on tasks (e.g. the Slurm executor submits jobs and monitors them for completion). I was considering adding a companion "verify" stage for every vertex, which would be a command that ran and verified output. It might be a way to do what I think you're describing above without having to build in a variety of expected outputs into the daggy core. I'll check what Luigi is doing, though.

> resuming a partially failed build

Daggy does this! Right now it will continue running the DAG until every path is completed or all vertices in a processing state (queued, running, retry, error) are in the error state, then the DAG goes to an error state.

It's possible to explicitly set task/vertex states (e.g. mark it complete if the step was manually completed), then change the DAG state to QUEUED, at which point the DAG will resume execution from where it left off. [1] is a unit test that walks through that functionality.

[1] https://gitlab.com/iroddis/daggy/-/blob/master/tests/unit_se...

I recently started working on my own DAG execution framework, after failing to get some patches into Airflow to make the scheduling easier to reason about.

My typical use case was orchestrating DAGs with thousands of vertices, and airflow would silently wedge itself and fail to report errors.

Daggy is just starting out, but I’m hoping it’ll become more robust and scalable as time goes on.

https://gitlab.com/iroddis/daggy