Obelisk 0.32: Cancellation, WebAPI, Postgres

Obelisk 0.32: Cancellation, WebAPI, Postgres

Obelisk 0.32 introduces cooperative cancellation for workflows and activities, a new WebAPI with multi-format support, and PostgreSQL support for multi-node deployments and high availability.

Cancellation

As discussed in the previous announcement, each function invoked by Obelisk, whether a workflow or an activity, must be fallible. As of v0.29.0 this includes persistent sleep as well. This enabled not only cancellation of activities and delay requests, but also a clean way of handling cancellation in the workflows:

workflow_support::sleep(ScheduleAt::In(SchedulingDuration::Seconds( 10 ))) . map_err (|()| MyWorkflowError::Cancelled)?; some_activity::send_request() . map_err (|()| MyWorkflowError::Cancelled)?; // Handle cancellation and running out of retry attempts.

Cancellation is performed either by using gRPC or the WebAPI discussed below.

The only way to cancel a workflow is to cancel its "leafs" - activites and delay requests. Some workflow engines support workflow cancellation, but the act of stopping workflow at the next step is not compatible with cleanup / compensating actions required for distributed sagas.

Obelisk only supports cooperative cancellation of workflows, which in turn makes writing compensating actions natural:

fn app_init ( org_slug : String, app_name : String, obelisk_config : ObeliskConfig, init_config : AppInitConfig, ) -> Result<(), AppInitError> { // Launch sub-workflows by using import. // In case of any error including a trap (panic), delete the whole app. workflow_import::prepare_volume(...) . map_err (| err | cleanup (...))?; workflow_import::wait_for_secrets(...) . map_err (| err | cleanup (...))?; workflow_import::start_final_vm(...) . map_err (| err | cleanup (...))?; workflow_import::wait_for_health_check(...) . map_err (| err | cleanup (...))?; Ok(()) }

source: obelisk-deploy-flyio

... continue reading