Repository navigation
Conversation
Add a documented subpath for people writing their own `Backend`. It exports the `Backend` interface and its param and result types, plus the helpers the built-in backends share for the rules that don't depend on storage: retry on failure, rerun, cancel conflicts, schedule occurrences, pagination, and row and error checks. A custom backend that uses them behaves the same way as the SQLite and Postgres backends. `openworkflow/internal` stays as it is for the CLI and dashboard. The new docs page marks the backend API as experimental before 1.0, so backends should pin the OpenWorkflow versions they support.
…ting Publish `testBackend()`, the suite the SQLite and Postgres backends run, so people can check a custom `Backend` against the same tests. Vitest becomes an optional peer dependency.
commit: |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| A backend owns its connections and its schema. `stop()` is called when the | ||
| client or worker shuts down. |
There was a problem hiding this comment.
The guide says the client or worker calls the backend’s stop(), but OpenWorkflow has no shutdown method and Worker.stop() never calls backend.stop(). Readers relying on this promise can leave database connections open. Say that callers must explicitly call backend.stop() after stopping their workers.
| A backend owns its connections and its schema. `stop()` is called when the | |
| client or worker shuts down. | |
| A backend owns its connections and its schema. Call `backend.stop()` explicitly | |
| when you're done with it, after stopping any workers that use it. The client and | |
| worker do not call it for you. |
This branch has not been deployed
1 participant
Follow-up to #880
Summary
As discussed in #880, this exposes the Backend API and the backend test suite so backends can be maintained outside this repo. The Drizzle backend will live in a separate
openworkflow-drizzlepackage that builds on both.Changes
openworkflow/backend: theBackendinterface and its param and result types, plus the helpers the built-in backends share for logic that doesn't depend on storage (computeFailedWorkflowRunUpdate,prepareWorkflowRerun,resolveCancelWorkflowRunConflict,nextScheduleOccurrence,isTerminalStatus, the cursor/pagination helpers,toWorkflowRunCounts,requireRow,wrapError). It only re-exports what the SQLite and Postgres backends already import fromcore/.openworkflow/testing:testBackend()andTestBackendOptions.filesre-includesdist/testing/backend.testsuite.*anddist/testing/schedules.testsuite.*, andvitestbecomes an optional peer dependency.testBackend. It says the backend API is experimental before 1.0 and may change in a minor release, so backends should pin the OpenWorkflow versions they support.I added
/backendas a new subpath instead of adding toopenworkflow/internal, sinceinternalis what the CLI and dashboard use and isn't documented. Happy to fold it intointernalif you'd prefer.The two exports are separate commits if you'd like to take only one.
Tested by packing the tarball into a scratch project, typechecking imports from
openworkflow/backend, and runningtestBackendfromopenworkflow/testingagainstBackendSqlite(86 tests pass).npm run cichecks pass locally.