Adopting OpenWorkflow in Last Light: feedback, and four proposals we'd like to contribute #877

Hi! We maintain Last Light, an open-source GitHub maintenance agent (MIT, by Nearform). It runs multi-step coding-agent workflows: triage, build → review → fix loops, and PR review pipelines. Approval gates can wait for days, and individual agent steps run 30–40 minutes. It deploys as a single-host docker-compose stack on SQLite by default, with Postgres optional.

We're replacing our home-grown YAML workflow engine with TypeScript workflows, and we've chosen OpenWorkflow as the runtime (design, decision issue). We compared it against DBOS, Absurd, Inngest, Restate, Temporal, Vercel Workflow, Mastra and others. It was the only one that is embeddable, needs no extra infrastructure, supports SQLite, and has real step checkpointing. In a spike on 0.10.1, a run parked at an approval gate survived a process restart, and after a kill -9 mid-step a fresh worker reclaimed the run with only the in-flight step re-running. Thank you for building it.

We'd like to be a public production user and to contribute, rather than work around things in an adapter. Per CONTRIBUTING, here are the gaps we hit, so we can check they fit your thinking before opening any PRs. We're happy to split any of them into separate issues, and to do the implementation.

1. A pluggable logger

Worker-loop errors go to console.error. Our runtime requires structured JSON logging with levels, so we'd like a logger option (for example { debug, info, warn, error }, defaulting to the console) on the client or worker.

2. A configurable lease and heartbeat

The 30 s lease is a constant. That's fine for us today, but deployments with very long steps or slow storage may want to tune it. We'd propose leaseMs / heartbeatMs worker options with the current values as defaults.

3. Signals sent before a workflow waits

sendSignal is dropped when no step is waiting yet. That's a natural race for approvals: a human approves before the run reaches waitForSignal, or during a restart. We currently treat our own approval row as the source of truth and check it before parking. Would you prefer buffered signals (persisted until consumed or expired), or a documented check-before-park pattern? We'd implement whichever fits your model.

4. Sharing a database with an existing application

The table names are fixed (workflow_runs, step_attempts, workflow_signals, openworkflow_migrations). workflow_runs collides with an existing table of ours, so CREATE TABLE IF NOT EXISTS silently no-ops and inserts then fail. As far as we can tell, namespace_id is a column rather than a prefix. Could the backends accept a table prefix or schema?

Relatedly, we want a single database file, our existing driver (libsql / pg), and our existing migration tooling, so we're implementing the Backend interface over Drizzle ORM (SQLite and Postgres). If it's useful, we'd like to contribute it upstream as a generic backend, e.g. @openworkflow/backend-drizzle, that takes an injected Drizzle db. Two questions on that:

• Is there a backend conformance test suite we should target? If not, would you welcome one, extracted from the existing SQLite/Postgres backend tests?
• How stable do you consider the Backend interface before 1.0?

We'll pin an exact version until 1.0 and follow the changelog. If any of these conflict with where you're taking the project, we'd rather know now and adapt our design. Thanks!