@voltro/plugin-rooms 0.89.0 → 0.89.1

package/CHANGELOG.md

@@ -41,6 +41,42 @@ _Changes staged for the next release accumulate here (rolled up from
 
 ---
 
+## [0.89.1] — 2026-11-06
+
+### Changed
+
+- **The framework runs on effect 4.1.2** — `@voltro/cli`, `@voltro/devtools`, `@voltro/runtime`, `@voltro/database`, `@voltro/voltro`, `@voltro/workflow`, `@voltro/sql-sqlite`, `@voltro/sql-mysql`, `@voltro/sql-mssql`, `@voltro/sql-postgres`
+
+  Every `@voltro/*` package now pins `effect` and its `@effect/*` companions to 4.1.2. `voltro update` moves the pins, the lockstep overrides and the version-keyed patch entries for you; a workspace you update by hand runs `voltro add patches` after pinning 4.1.2, which writes the 4.1.2 patch files and retires the 4.1.0 entries.
+
+  The Effect releases fix durable workflows on a cluster: a transient storage failure while saving a durable clock or a deferred completion is retried instead of failing the workflow, a forced shard release no longer blocks the shard from being taken over again, and a runner that lost its shard can no longer delete a newer activity result, which could run the activity twice. On MySQL and MariaDB an interrupted statement is now stopped with `KILL QUERY` instead of running on, and every statement checks out its own pool connection. `BigDecimal` parsing rejects scales beyond ±10,000.
+
+### Fixed
+
+- **Every broadcast listener retries a refused subscribe** — `@voltro/plugin-broadcast`, `@voltro/cli`
+
+  A replica whose broker refused a subscribe at boot (a Redis or NATS restart while the replica started) stayed deaf on that channel until the process restarted, after one warning: cross-replica events reached only the replica that published them, instance membership saw only itself, a web process never heard ISR revalidations from the api, and the workflow wake stayed on the poll interval. Only the change bus retried. Each of these listeners now keeps trying, from 0.5 s doubling to 10 s, logs the first refusal once and logs again when it subscribes; meanwhile it degrades as before. `retryingSubscribe` in `@voltro/plugin-broadcast` is the primitive they share, for a plugin's own listener too.
+- **The doctor's provider-copy check covers community AI provider packages** — `@voltro/cli`
+
+  `voltro doctor` reported `aiProviderSkew: null` while `voyage-ai-provider`, which `@voltro/ai` loads by name, resolved an older `@ai-sdk/provider` than `ai` and the `@ai-sdk/*` packages. The check looked at a fixed list of package names. It now checks `ai`, `@voltro/ai` and every package the app or `@voltro/ai` declares that itself depends on `@ai-sdk/provider`, and its suggested update command names the additional packages it found.
+- **Workflow steps on SQL Server keep their replies when the pool is busy** — `@voltro/cli`, `@voltro/workflow`
+
+  Before it stores a step's reply, the workflow runner confirms that it still owns the step's shard. On SQL Server that check borrowed a pooled connection, and a step annotated `WithTransaction` makes it while its transaction holds one. When such steps held every connection, the check waited out its 10 s deadline and the reply was discarded; with 24 concurrent steps on a pool of 3, about one run in twenty left workflows unfinished. The runner now reserves one connection for its shard locks on SQL Server, as it already did on PostgreSQL and MySQL/MariaDB. The connection counts against `DB_MAX_CONNECTIONS`: the `db pool:` boot line lists it as held for the life of the process, and the journal bound is computed from the rest (4 of 10 instead of 5). `voltro update` writes the patch that carries the change.
+- **SQL Server transactions that start workflows no longer block each other** — `@voltro/cli`
+
+  Starting a workflow writes to the workflow journal inside the app's transaction. On SQL Server that write looked its key up with an `NVARCHAR` parameter against a `VARCHAR` column, which scans instead of seeking, and inserted with `MERGE … WITH (HOLDLOCK)`. A transaction that had started a workflow held up every other transaction starting one until it committed, and two of them could deadlock: SQL Server rolled back the whole transaction of one (error 1205). The patch to `effect/cluster` that the CLI ships now seeks the unique index and inserts without range locks. Two transactions starting different workflows no longer wait for each other. `voltro update` writes the new patch; on a project you do not update, run `voltro add patches` and `pnpm install`.
+- **A PostgreSQL boot no longer deadlocks with replicas that are already running** — `@voltro/cli`, `@voltro/database`
+
+  Two replicas starting together on PostgreSQL could lose one of them at boot with `40P01 deadlock detected` between `_voltro_field_keys` and `_voltro_field_key_holders`. Every boot took ACCESS EXCLUSIVE locks on tables other replicas were writing, even when there was nothing to change: the Timeline capture setup locked every captured table in name order before comparing its contract, and the framework bootstrap re-ran `ALTER TABLE … REPLICA IDENTITY FULL` and its change triggers on every reactive framework table. A running replica's field-key heartbeat — key rows first, then its lease — closed the cycle, and the error ended the booting process. Both now read the catalog first and take no table lock when nothing changed. When the Timeline contract did change, its locks are taken under a short lock timeout, so the install yields to running transactions and retries; after eight lost attempts startup continues without Timeline history and says so.
+- **Presence shares its roster across replicas under `voltro serve`** — `@voltro/plugin-presence`, `@voltro/plugin-broadcast`
+
+  Under `voltro serve`, presence logged `crossInstance: false` and `presence: could not subscribe` on every boot, so with two replicas each roster showed only the members connected to that pod. `voltro serve` binds plugins before it activates them, and the broadcast plugin refused any use before its own activation, so presence's subscription failed at binding and was never retried. The broadcast provider now waits for its activation and fails with a reason only if activation fails or never comes. Presence retries a refused subscription with backoff (0.5 s, doubling to 30 s) and reports `crossInstance: true` once one succeeds, which also recovers from a broker that was briefly unreachable at boot. A broadcast failure now says why: the plugin's own refusals carry their message, and a broker or driver error carries its kind and operation, never the driver's text.
+- **A step whose reply was discarded runs again instead of stalling its workflow** — `@voltro/cli`
+
+  When the runner could not confirm a step's shard after the step ran, it discarded the reply and delivered the request again. The step had already used up its registration, so the second delivery was answered as suspended and the workflow waited with nothing left to resume it. The waiting run now resets the attempt and runs the step again. Steps are at-least-once, so a step can run twice in this case, as it can after any retry. The fix is part of the `effect/cluster` patch the CLI ships and applies to every dialect; `voltro update` writes it.
+
+---
+
 ## [0.89.0] — 2026-11-05
 
 ### ⚠ BREAKING

package/THIRD-PARTY-NOTICES.md

@@ -3900,7 +3900,7 @@ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.
 ```
 
-## @effect/platform-node@4.1.0
+## @effect/platform-node@4.1.2
 
 License: MIT
 
@@ -3928,7 +3928,7 @@ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.
 ```
 
-## @effect/platform-node-shared@4.1.0
+## @effect/platform-node-shared@4.1.2
 
 License: MIT
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@voltro/plugin-rooms",
-  "version": "0.89.0",
+  "version": "0.89.1",
   "description": "Room simulation and API control sources; integration remains unverified",
   "keywords": [
     "voltro",
@@ -164,18 +164,18 @@
     "node": ">=24.0.0"
   },
   "dependencies": {
-    "@voltro/database": "0.89.0",
-    "@voltro/kv": "0.89.0",
-    "@voltro/plugin-storage": "0.89.0",
-    "@voltro/protocol": "0.89.0",
-    "@voltro/runtime": "0.89.0",
-    "@voltro/workflow": "0.89.0",
-    "@voltro/plugin-licensing": "0.89.0"
+    "@voltro/database": "0.89.1",
+    "@voltro/kv": "0.89.1",
+    "@voltro/plugin-storage": "0.89.1",
+    "@voltro/protocol": "0.89.1",
+    "@voltro/runtime": "0.89.1",
+    "@voltro/workflow": "0.89.1",
+    "@voltro/plugin-licensing": "0.89.1"
   },
   "peerDependencies": {
-    "effect": "4.1.0",
+    "effect": "4.1.2",
     "react": "^19.0.0",
-    "@voltro/cms": "0.89.0"
+    "@voltro/cms": "0.89.1"
   },
   "peerDependenciesMeta": {
     "react": {