@adonis-agora/durable 1.0.0-rc.2 → 1.0.0-rc.4

package/CHANGELOG.md

@@ -1,5 +1,34 @@
 # @adonis-agora/durable
 
+## 1.0.0-rc.4
+
+### Major Changes
+
+- [#490](https://github.com/DavideCarvalho/adonis-agora-durable/pull/490) [`89e0305`](https://github.com/DavideCarvalho/adonis-agora-durable/commit/89e030531c92be31657ba10519ff033b330bcbbe) Thanks [@DavideCarvalho](https://github.com/DavideCarvalho)! - A compensating cancel no longer writes or reads a buffered `cancel:<runId>` marker. The persisted `cancelling` status is the durable intent: a turn picks it up at start, and a turn already running on another pod when the cancel lands finds it at its settle (the status check no longer matches) and runs the saga undo there, on every exit (return, throw, continue-as-new, suspend). Every turn exit saves a buffered-signal read and re-write.
+  
+  Upgrade note: stop pre-1.0 engines before or while deploying 1.0. They rely on the marker 1.0 no longer writes, so while one of them still executes a run, a compensating cancel issued from a 1.0 pod can wait for crash recovery before its undo runs.
+
+### Patch Changes
+
+- [#493](https://github.com/DavideCarvalho/adonis-agora-durable/pull/493) [`267b719`](https://github.com/DavideCarvalho/adonis-agora-durable/commit/267b7199d2e07a5e720d4d2de91b235f736056dc) Thanks [@DavideCarvalho](https://github.com/DavideCarvalho)! - The db transport's run queue no longer takes runs after its consumer's `stop()` resolved. A poll that was already in flight when `stop()` was called (waiting on the claim's read) could claim runs dispatched afterwards and hand them to the handler. `stop()` now waits for that poll, and a poll that finds the consumer stopping gives back what it claimed.
+
+## 1.0.0-rc.3
+
+### Major Changes
+
+- [#486](https://github.com/DavideCarvalho/adonis-agora-durable/pull/486) [`ab26861`](https://github.com/DavideCarvalho/adonis-agora-durable/commit/ab26861edb93aefad8aa949f32913b6d3681c519) Thanks [@DavideCarvalho](https://github.com/DavideCarvalho)! - A compensating cancel now persists a new run status, `cancelling`.
+  
+  `engine.cancel(runId, { compensate: true })` marks the run `cancelling` before it returns, and returns that status. The run keeps it while the saga's compensations run, then becomes `cancelled`. While it is `cancelling`:
+  
+  - A repeat `cancel()`, with or without `compensate`, returns `cancelling` and leaves the undo alone. Before, a second cancel without `compensate` marked the run `cancelled` and skipped the compensations still running.
+  - Crash recovery re-drives it on any instance, so an undo whose pod died is finished elsewhere.
+  - It keeps its singleton and concurrency slot, `waitForRun` keeps waiting, `engine.requeue()` returns it unchanged, and an `overlap: 'skip'` schedule doesn't fire over it.
+  - The dashboard and the API show it as its own status, with a filter chip.
+  
+  A failed write of the cancel request now fails `cancel()` instead of being ignored, and leaves the run as it was.
+  
+  **Breaking:** `RunStatus` has a new member, `cancelling`. Exhaustive `switch`es over `RunStatus` need a case for it. A custom `StateStore` must return `cancelling` runs from `listIncompleteRuns` and `listOrphanedRuns` (the new `RECOVERABLE_RUN_STATUSES` lists them, and the state-store conformance suite checks it), or recovery won't finish a crashed compensating cancel.
+
 ## 1.0.0-rc.2
 
 ### Patch Changes