Nice catch. Fixing it :)

It's not recommended--the assumed model is that every workflow finishes on the code version it started. This is managed automatically in our hosted version (DBOS Cloud) and there's an API for self-hosting: https://docs.dbos.dev/typescript/tutorials/development/self-...

That said, we know sometimes you have to do surgery on a long-running workflow, and we're looking at adding better tooling for it. It's completely doable because all the state is stored in Postgres tables (https://docs.dbos.dev/explanations/system-tables).

The main use case is to build reliable programs. For example, orchestrating long-running workflows, running cron jobs, and orchestrating AI agents with human-in-the-loop.

DBOS makes external asynchronous API calls reliable and crashproof, without needing to rely on an external orchestration service.

That work is done by the decorators! They wrap around your functions and store the execution state of your workflows in Postgres, specifically:

- Which workflows are executing

- What their inputs were

- Which steps have completed

- What their outputs were

Here's a reference for the Postgres tables DBOS uses to manage that state: https://docs.dbos.dev/explanations/system-tables

Each workflow is tagged by the executor ID that runs it. You can command each new executor to handle a subset of the pending workflows. This is done automatically on DBOS Cloud. Here's the self-hosting guide: https://docs.dbos.dev/typescript/tutorials/development/self-...

You'll need to click either the Python or TypeScript icon. We support both languages and will add more icons there.