FlowChassis 0.1.0 Released as an Open Source Workflow Kernel for Go
FlowChassis 0.1.0 is out. It is a small workflow execution kernel for Go: you describe a job as steps, and it runs them inside your own program, writes a checkpoint before and after every step, retries what fails, undoes what can’t finish, and carries on after a crash from exactly where it stopped. It is open source under the Apache License 2.0.
There is no server to run and no database to set up. The whole thing is a library and one journal file. The library needs nothing outside the Go standard library, so adding it pulls in no other modules at all.
The idea is simple. Most programs that do multi-step work already need what a workflow engine does: they charge a card and then book a courier, or create an account and then provision it, and they need to know what to do when the process dies in the middle. Fewer of them need a workflow platform. FlowChassis is the engine without the platform.
What 0.1.0 Can Do
A flow is a list of named steps, each with a Do and, if it needs one, an Undo. Runs go from step to step, or to a step one of them chooses. Each step gets the run’s input and its state, a set of named values that is saved with the checkpoint only when the step succeeds, so a failed attempt leaves nothing half-written behind.
When a step fails, it is tried again after a wait that grows each time. When it fails for good, the run compensates: the undo of every completed step runs, newest first, and each undo sees the state exactly as its own step left it. A refund knows which charge it reverses. Runs can be canceled, which compensates them too.
Every step also gets an idempotency key that stays the same across attempts and restarts. That matters, because steps run at least once. A step cut off by a crash runs again on the next start, and the key is how the payment provider knows the second charge is the first one again.
The flowchassis command reads journals: it lists runs, prints the full history of any run with times, checks every record’s checksum, and compacts the file. It can do that while your program has the journal open.
How It Was Tested
The promise is recovery, so the testing is mostly about killing things. The crash demo runs 1,000 orders through a five-step flow, 16 at a time, in a worker process that gets killed with SIGKILL 200 times at random moments. Every order ended the way its own rules said, 750 completed and 250 compensated, and every effect its steps had on the outside world matched what the journal recorded. Another test cuts the journal at every byte of its last record, and each cut opens and resumes. The testing post goes through it all.
On speed: every checkpoint is flushed to disk before its step moves on, so the disk sets the pace. Records written at the same moment share one flush, which is why throughput grows with concurrency. On a small 2-CPU cloud machine, empty steps ran at about 1,800 a second with one worker and 26,000 with 64.
Getting It
go get github.com/flowchassis/flowchassis@latest
The quick start builds a flow you can kill and watch resume, in five minutes. The download page has the command-line tool for Linux, macOS and Windows, and the reference lists every call. The code is on GitHub.
Version 0.1.0 runs in one process per journal, on one machine. That’s the scope on purpose. A kernel should be small enough to read in an afternoon.