TL;DR
Obelisk 0.32 introduces cooperative cancellation for workflows and activities, a WebAPI that serves text and JSON over HTTP on the existing server port, and support for PostgreSQL to enable multi-node deployments and high availability. These updates change how cancellations propagate, expand API access options, and provide a path off SQLite for production-grade setups.
What happened
The Obelisk 0.32 release formalizes cooperative cancellation across workflows and activities: every invoked function must be able to fail, including persistent sleep, allowing cancellation to be handled as an error inside workflow code. Cancellation requests are issued either via gRPC or the server's HTTP WebAPI, but Obelisk cancels by terminating leaf operations (activities and delay requests) rather than forcibly advancing workflow state. That cooperative pattern makes it straightforward to implement cleanup or compensation logic in top-level workflows. Separately, the server's port 5005 now accepts text-over-HTTP responses and JSON output for execution queries, expanding beyond gRPC and gRPC-Web access. Finally, PostgreSQL is offered as an alternative to the built-in SQLite+Litestream approach; Postgres supports multi-node configurations and high availability and is configured via obelisk.toml.
Why it matters
- Cooperative cancellation lets workflows handle interrupts as errors, simplifying cleanup and compensating actions.
- HTTP-accessible WebAPI with JSON output lowers friction for scripting and integration without gRPC clients.
- Postgres support enables multi-node deployments, removing a single point of failure that can exist with local SQLite replicas.
- Organizations that need high availability and dynamic scaling can rely on a traditional DB backend instead of asynchronous-replica setups.
Key facts
- Release: Obelisk 0.32 (features described in the source).
- Cancellation: functions invoked by Obelisk (workflows, activities, persistent sleep) must be fallible so cancellation can be handled by workflow code.
- Cancellation operations target leaf elements—activities and delay requests—rather than forcibly stopping a workflow mid-step.
- Cancellation can be triggered through gRPC or the WebAPI.
- WebAPI: server listens on port 5005 and now serves text-over-HTTP and JSON for execution queries in addition to gRPC and gRPC-Web.
- The WebAPI example in the source shows human-readable lines and a JSON array response for execution listings.
- Obelisk previously relied on SQLite with Litestream for backups; that model may lose the last few seconds of committed transactions on VM crashes due to asynchronous replication.
- PostgreSQL support adds multi-node deployment capability, enables high availability, and is configurable via obelisk.toml.
What to watch next
- Check obelisk.toml for PostgreSQL connection and cluster configuration when planning upgrades or multi-node deployments.
- Whether official migration tooling or step-by-step guides from SQLite+Litestream to Postgres will be published: not confirmed in the source.
- Performance and operational guidance for large-scale WASM component distribution across nodes: not confirmed in the source.
- Any future changes to WebAPI authentication or rate-limiting behavior for HTTP endpoints: not confirmed in the source.
Quick glossary
- Cooperative cancellation: A cancellation approach where running tasks must observe and handle cancellation requests themselves, typically by returning an error or stopping at cancellation points.
- WebAPI: An HTTP-based application programming interface that can return responses in plain text or structured formats like JSON for programmatic access.
- PostgreSQL (Postgres): An open-source relational database commonly used for production workloads that require transactions, replication, and high availability features.
- SQLite: A lightweight embedded SQL database often used for local development or single-instance deployments.
- Litestream: A tool often used with SQLite to stream WAL changes to remote object storage for backups and point-in-time recovery.
Reader FAQ
How are workflows canceled in Obelisk 0.32?
Workflows are canceled cooperatively by cancelling leaf operations such as activities and delay requests; cancellation is observed as an error by the workflow code.
Can I call the Obelisk API without a gRPC client?
Yes. The server on port 5005 serves text-over-HTTP and JSON output in addition to gRPC and gRPC-Web.
Does Obelisk support PostgreSQL for production/high-availability?
Yes. PostgreSQL support is available and can be configured through obelisk.toml to enable multi-node deployments and high availability.
Is there an automatic migration path from SQLite+Litestream to Postgres?
not confirmed in the source
Obelisk 0.32: Cancellation, WebAPI, Postgres 2025-12-29 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….
Sources
Related posts
- AI Is Forcing Us to Write Good Code — When Best Practices Are Best
- Production failure from uninitialized C++ struct exposed undefined behavior
- Static memory allocation in Zig: building a Redis-compatible kv server