I stopped Jazz's client type definitions from exposing details that change between Better Auth releases. This keeps normal Better Auth type checking working while preserving Jazz's own account and action types, with checks for the 1.6 setup.
I made Jazz check integer values before passing them to native code. It now gives clear errors for fractions, non-finite values, and numbers outside the signed 32-bit range, with documentation and boundary tests.
I updated the repository's Next.js users to the patched 15.5.21 release and centralised the version pins. I also fixed the formatting and lint issues needed to validate the update.
I fixed Jazz's Better Auth client types so they no longer expose version-specific internals from Better Auth. That keeps normal Better Auth inference working while retaining Jazz-specific account and action types, and adds a compatibility check.
I fixed a problem where deletes in migrated data could lose the row's earlier history. I made Jazz resolve that history from the row's origin records and rebuild the right branch state, with tests for deletes, renames, permissions, and recovery.
I fixed a TypeScript inference issue where chaining column modifiers could throw away specialised types. The stored, displayed, and inserted value types now stay distinct and accurate, with regression tests.
I updated the shared Next.js version used by Jazz's workspaces to 16.2.11, which includes security fixes. I also adjusted the docs image route so the static site could build all of its images again.
I fixed a timing problem where a live browser session could be mistaken for an abandoned one while it was still saving. The cleanup now waits for evidence that a session is really abandoned, so concurrent tests do not lose stored sessions.
I updated the shared Next.js version to 16.2.11 across the affected workspaces. I also fixed the docs image route so the new version can build all static images.
I fixed a race where an active browser session could look abandoned before its local save finished. Jazz now waits until the session is truly unused before reclaiming it, with coverage for concurrent session acquisition.
I made rejected writes stay rejected while a client reconnects or replays its history. Dependent rows remain hidden, and already-accepted rows are not sent back to the server that supplied them, so a permission change cannot silently retry the original write.
I made direct batches settle safely before their rows become visible. Jazz now loads every member and saves the recovery state first, so a failed load cannot publish only part of a batch, and an interrupted publication can be completed after a retry or restart.
I brought the Jazz guides and example apps back in line with how the project works today. I updated the explanations for server authentication, subscriptions, SQLite, the Inspector, and framework examples, and refreshed the generated MCP docs index. I also removed an unused font and added checks so the docs are less likely to drift again.
When multiple devices write to the same list at the same time in a collaborative app, the default behaviour is "last writer wins" — one write silently wipes out the others. I added a new merge strategy called a "grow-only set" for array columns: instead of one write winning, the list always grows to include everything anyone ever wrote, and all devices converge to the same sorted result. Once an element is added it can never be removed by a concurrent write, making it safe for things like tags or participant lists where losing data would be worse than seeing a duplicate.
I fixed a crash that affected Jazz apps when production bundlers left the browser broker worker's imports unresolved. The build now bundles that worker as a self-contained file, so Next, Vite, and other bundlers can start it without extra application-specific configuration.
Jazz has bindings for React, Svelte, and Vue, but if you wanted to build a binding for another framework, you'd have to dig into the package's internals. I added a new jazz-tools/shared entry point that exposes the core utilities — the helpers that turn a live query into a reactive, in-place-updated result — so external developers can build custom bindings without touching anything private. The React, Svelte, and Vue bindings were also updated to import from this new public surface instead of deep internal paths.
Jazz apps use a SharedWorker — a background browser thread — to coordinate data between tabs. The worker file was shipped with references to other files using bare paths, but bundlers like Webpack, Turbopack, and Vite in production mode couldn't recognise it as a worker entry, so they copied it verbatim and those references would 404, crashing every Jazz app with "Browser broker SharedWorker failed to start." I fixed this by bundling the worker into a single self-contained file at build time, so it works correctly regardless of which bundler the app uses.
The Svelte and Vue versions of Jazz were creating a brand new WASM runtime (a compiled binary module for running encryption and sync logic) for every client created on the page. If you mounted multiple Jazz-powered components for the same user, you'd end up with several runtimes all fighting over shared memory — causing "out of bounds" crashes. I fixed this by sharing a single WASM runtime instance across all clients on the page.
I fixed a cluster of bugs in useAll and QuerySubscription — the hooks that let you query and subscribe to collections of data — across the React, Svelte, and Vue versions of Jazz. The bugs meant these hooks behaved differently depending on which framework you were using, and some edge cases returned incorrect results. I brought all three frameworks into parity and fixed the underlying orchestrator that coordinates subscriptions.
I fixed a problem where session changes weren't properly propagating in the Svelte and Vue integrations for Jazz. In Svelte, getSession() now returns a stable handle that always reads from the underlying reactive state, so switching sessions updates every consumer without tearing down the provider. In Vue, useSession() now returns a computed reference derived from the injected client, so any template or computed value that uses it automatically re-renders when the session changes.