pipework 0.88.0 → 0.89.0

package/CHANGELOG.md

@@ -1,5 +1,14 @@
 # Changelog
 
+## 0.89.0
+
+- **New: a job can end an attempt as "later" or "permanent"** (#535). `throw jobs.later(message, { delayMs })` puts the job back to `pending` after `delayMs` (default: the queue's backoff, at least 1 s) without counting an attempt, so a service that is busy or down never dead-letters it. `throw jobs.permanent(message)` dead-letters it now, whatever attempts remain, and calls the dead-letter listeners. Both work in any `.job()` handler and in a step's `run`: a later step stays queued, and a permanent one fails its run at once and calls `onFailed`. The next attempt's trace opens with `pipework.job.restart`, reason `'later'`. New `queue.later(...)` and `queue.fail(..., { permanent: true })`.
+- **Changed: a step's `run` holds no transaction** (#534). One short transaction reads the run's state before `run`, and another records the result and advances the run after it. A slow step no longer holds a connection idle in transaction. `ctx.checkpoint(fn)` runs database work in its own short transaction as the run's tenant. `ctx.withResult(fn)` registers writes that commit in the same transaction as the step's result. `pipe()` inside `run` now finds no transaction: use `ctx.checkpoint`.
+
+## 0.88.1
+
+- **Fixed: under the test harness, two transactions started from one block take turns** (#526). Before, a transaction started without being awaited (a trace closing after `asLink`) and the route's next one were open together as sibling savepoints. Releasing the first also released the second, so the request answered 500 (`3B001`). Now the second waits for the first to settle, as calls outside any block already did. A transaction started inside another still nests in it at once.
+
 ## 0.88.0
 
 - **New: a step names the class of worker that takes it (`workers: 'model'`)** (#531). Its jobs are typed `pipework.step.<graph>:<class>` (the default class keeps `pipework.step.<graph>`), and `createWorkerSurface({ graphs: [graph.workers('model')] })` takes only those classes. Run one surface per class to give each class its own concurrency. One run keeps one status, plan, cancel and fan-in across classes, and every step keeps the run's priority.