redb releases

Security

• Every SQL sink that shoved a caller-supplied string into the statement refuses it now (external security review of the SQL sinks). PostgreSQL was already fail-closed (values through %L, identifiers through %I, an unknown field raises), so the holes were in the two SQL modules and in shared C# code:

  • SQL Server Free: the filter builder echoed a raw name inside a comment. pvt_b2_expr_sql answered an unknown $field and an unknown $expr node with /*unknown-b2-...: <name>*/NULL, and pvt_build_window_expr did the same with the window function name, so a */ in the name closed the comment and the rest of it became live T-SQL. All three paths call dbo.pvt_fail now, where the PostgreSQL module raises.
  • SQLite Free: the operand builder pasted the operand as it stood. pvtAppendOperand (redb_pvt.c) spliced the text of a JSON string unquoted whenever the column was not a text column, so {"Age": "1 OR 1=1 --"} reached the statement verbatim. The builder is total now: a string against a non-text column must be a plain numeric literal, a number is validated as a literal before it is spliced, and any other token type (array, object, unknown) is refused through the new pvt_refuse(...) function. No splice can carry anything but a validated number.
  • SQLite Free: the extension loader stayed on. SqliteDataSource.LoadNativeExtension called EnableExtensions(true) and never turned it back off, so any injection on that connection could call load_extension() and run arbitrary code. The flag goes back to false in a finally.
  • Window function name, every dialect, Free and Pro. WindowFuncRequest.Func is a public settable string and every provider appended it as func + "()", so a name carrying a quote, a bracket or a comment marker reached the statement. The new redb.Core.Query.Window.WindowFunctionName accepts a plain identifier only (letters, digits, underscore, up to 64 characters) and throws otherwise; the nine call sites (three Free, six Pro) go through it.
  • QuoteIdentifier, every dialect, wrapped the name without escaping. a]b; SELECT 1-- closed the identifier on SQL Server, a"b did on PostgreSQL and SQLite. Each dialect doubles its closing quote now.
  • UserProviderBase.EscapeLikeWildcards on SQL Server. T-SQL LIKE reads [ as a character-class opener, so an exact email search for [s] matched a user it must not match. The escape follows a dialect flag now (LikeBracketIsWildcard, true on SQL Server only); PostgreSQL and SQLite keep [ as an ordinary character, where escaping it would change the search itself.

Fixed

• DeleteSubtree is atomic. TreeProviderBase.DeleteSubtreeWithUserAsync deleted the subtree values in one statement and the objects in the next; when the second failed (a live foreign key pointing into the subtree) the first was already committed, and the objects stayed with their values gone. Both statements run in one ExecuteAtomicAsync now.
• A dictionary field is refused when its runtime value cannot be stored. A property typed IDictionary<K,V> (or Dictionary<K,V>) whose instance was a SortedDictionary, a ConcurrentDictionary, an ImmutableDictionary or any other IDictionary<K,V> implementation other than Dictionary<K,V> was skipped in silence, and under DeleteInsert the stored values had already been deleted, so the field disappeared. The save path refuses it now, naming the field and the runtime type, and it refuses while the value records are built, i.e. before anything is written. Pinned by SqliteDictionaryInterfaceRefusalTests (the refusal leaves no object behind, and a plain dictionary in the same interface-typed property round-trips).
• SQL Server Free: a $case expression now contributes its fields. The $case branch of pvt_extract_field_pairs was unreachable: the value of $case is an array, so the generic array descent took it first and walked the {when,then} arm objects as plain objects. That harvested when/then/else as field paths and never reached the {"$field": ...} references inside the arms, so a filter whose expression used $case over a props field reached the expression builder without that field (a silently NULL term before 0.2.27, an error after it). The generic descent skips $case now and the dedicated branch walks the arm values, the way the PostgreSQL module already did. Module version 0.2.28; pinned by the module's own smoke runner (MsSqlModuleSmokeTests, 195 cases, none failing).

Changed

• A request that used to be answered with a comment, a NULL or a pasted name throws now. These shapes come from hand-built JSON filters and window requests, not from LINQ: an unknown $field or $expr node and an unsupported window function name on SQL Server Free (module 0.2.28), a non-numeric string against a non-text column on SQLite Free (extension 0.6.8), a WindowFuncRequest.Func that is not a plain identifier on any provider. The exception message says what was refused.
• Versions: the SQL Server module is 0.2.28, the SQLite extension 0.6.8 (99_module_version.sql with MsSqlDialect.Query_PvtRequiredVersion(), and PVT_MODULE_VERSION in redb_pvt.c with SqliteDialect.Query_PvtRequiredVersion()). The module ships inside the package and rolls over on the next start; the extension is a native binary, and redb.SQLite carries it rebuilt for win-x64, linux-x64 and linux-arm64 (there is no macOS binary, as before). A stale extension is refused at start-up on the version mismatch instead of running the old sinks quietly, which is what the gate is for.
• Documentation brought back in line with the code (external review 0, 1.9, 4.6). The storage note in the README now says that each property is a row in _values with an indexed, type-driven value column, instead of implying a dedicated column per property; decimal is documented as NUMERIC(38,18) (REAL on SQLite by default, TEXT in the exact mode) rather than numeric(18,4); and the user-table no longer claims SHA256 + salt, which is only the legacy format, since bcrypt is the default. The same stale claim was fixed in the SqliteUserProvider comment, in the Serena memories, and in the SqliteDialect note that described the SQLite v2-pvt SQL folder as deployed SQL.

Added

• Tests for every sink above and for the atomic delete: MsSqlInjectionHardeningTests, SqlitePvtOperandInjectionTests (refusal, subquery operand, numeric string still accepted), WindowFunctionNameTests, QuoteIdentifierDoublingTests, SqliteDeleteSubtreeAtomicityTests, SqliteDictionaryInterfaceRefusalTests.

Added — an ActivitySource for redb.Core database commands

• redb.Core now declares its database operations on an OpenTelemetry ActivitySource named redb.Core (redb.Core.Diagnostics.RedbActivitySource). Every command that goes through a context shortcut (QueryAsync, QueryFirstOrDefaultAsync, ExecuteScalarAsync, QueryScalarListAsync, ExecuteAsync, the JSON calls) opens one span carrying the operation name (db.operation = query / scalar / execute / json) and db.system = redb, and marks it an error when the command fails. A caller's cancellation is recorded but not marked an error. The statement's text and its parameters are never put on the span.
• Off by default. The source is inert until a consumer subscribes with AddSource(RedbActivitySource.SourceName); with no listener the shortcut calls the connection straight through, so nothing is emitted and nothing is allocated. This is the shape EF Core uses for its own Microsoft.EntityFrameworkCore source: the engine owns the source and the application opts in by name. In a route, a bean that reaches REDB through redb.Route.Core now shows the time spent in the database as a child span of the route instead of an empty gap. The nested Npgsql / SqlClient provider spans sit under it when those sources are subscribed too.

Fixed — a module packed by redb-worker now loads on a Tsak worker

The template's packing script put the manifest, the module config and the module assembly into the .tpkg and nothing else, so a module that uses a transport the worker does not ship (redb.Route.File, redb.Route.GenericFile) failed on its first start with FileNotFoundException — the .tpkg is the unit of deployment, and a consumer has no way to add the missing assembly afterwards. The package now carries every dependency the worker does not already provide; what the worker provides is listed in the deploy/shipped-module-deps.txt of each module template, and the real contents are written next to the package as <package>.contents.txt.

Fixed — the Razor template answers the same numbers on every machine

redb-razor bound decimal with the server's culture: on a machine set to a comma decimal separator the price a browser posted as 123.45 was rejected with The value '123.45' is not valid for 'Price'. — a template that works in one region and fails in the next. The site pins the invariant culture and prints prices with it, so a form behaves the same everywhere; the README shows the one-line change that follows the caller's locale instead.

Fixed — the Blazor WebAssembly client ships the .NET 10 asset layout

redb-app served _framework/blazor.webassembly.js while the .NET 10 SDK publishes the fingerprinted layout, and the client host project missed OverrideHtmlAssetPlaceholders, so a published page could go out with a literal #[.{fingerprint}] still in its markup. The index carries the import map, the preload links and the fingerprinted loader now, and the property is set.

Fixed — the chat template reads its configuration before it creates anything

redb-chat hard-coded SetMinimumLevel(LogLevel.Warning), so Logging:LogLevel:Default — and the environment variable behind it — could not switch the route-step logging on, which is the one thing you need while wiring a model. It also created redbchat.db before noticing that the LLM key was missing. The level comes from configuration, the key is checked first, and the README states the HTTP endpoint the template exposes.

Fixed — the console template builds clean, and the worker's README is true again

dotnet new redb built with a CS8602 warning on the nullable result of LoadAsync; the warning is gone. The redb-worker README no longer claims that a file which is not valid XML lands in data/error — it is answered with a Rejected receipt and archived like any other schema violation.

Added

• redb.Templates is a collection of seven templates. Each one runs as is: SQLite with Pro, the PVT prefilter and change tracking on, the props cache off with the lines that turn it on in a comment. Every project that has a database also ships a Dockerfile and compose files for PostgreSQL and SQL Server.

  • redb: the console app, as before.
  • redb-razor: a Razor Pages site - a product list with search, sorting and paging in the database, and a create / edit form.
  • redb-blazor: the same as a Blazor site (Interactive Server), plus a category tree. Components take an IRedbService per operation (RedbWork), not one per circuit.
  • redb-worker: an integration worker - a folder inbox, an XSD check, one .Transacted() write to redb, a receipt in the outbox; a repeated order is answered as a duplicate through the object's unique key.
  • redb-chat: an LLM chat on redb.Route.Llm with the history in redb, in the console and over HTTP. --tools none|shell|mcp adds a read-only system-command tool or the tools of an MCP server; --audit stamps the user and audit tags on every message and reads them back with a LINQ query. The API key goes into appsettings.json; a comment there shows how to switch to DeepSeek.
  • redb-app: a Blazor WebAssembly client and a REST DSL API with sign-in (JWT through InboundAuth=Bearer), CORS for development and nginx on one origin for deployment.
  • redb-bff: a Blazor Server backend-for-frontend with a cookie session, and a backend of redb.Route controllers that only the web server may call, with a service key.

  The route-based templates (redb-worker, redb-chat, and the servers of redb-app and redb-bff) are a module with InitRoute.main plus a host that calls it. The same module runs in its own host or on a Tsak worker: deploy/pack-tpkg.ps1 packs it, deploy/docker-compose.tsak.yml runs it on the Tsak stack image, and one set of setting keys and environment variables works in both places.

Changed

• The redb console template turns on the PVT prefilter and change tracking in its Pro variant; they were commented out. The props cache stays off, with the lines that turn it on next to it.

• SQL Server Pro: string matching follows the contract of COLLATION.md, as SQL Server Free does. Plain Contains / StartsWith / EndsWith were forced case-sensitive (COLLATE Latin1_General_CS_AS) whatever the column said; they now keep the column collation - case-insensitive on the default one. The *IgnoreCase forms were forced to Latin1_General_CI_AI, which also ignored accents (muller found Müller); they now fold case only, with LOWER. On the same database Free and Pro answered the same query differently; they agree now. Code that relied on Pro's case-sensitive plain match on a case-insensitive database should say so with an ordinal re-check in memory, as COLLATION.md describes. The prefilter renderer changed with it, so it stays a superset of the filter.

• Configuration copying has one list of settings. RedbServiceConfiguration.CopyFrom copies every setting, CopyBehaviourFrom every setting except the connection identity (ConnectionString, CacheDomain); Clone, ApplyTemporary and the validator's auto-fix go through them. The Clone extension method in RedbServiceConfigurationExtensions is removed - the instance method always won over it, so only an explicit static call reached it.

• The obsolete InitializeAsync / AutoSyncSchemesAsync extensions delegate to IRedbService.InitializeAsync. They carried their own copy of the start-up sequence: schemes synchronized in parallel on one service instance, no up-front validation of scheme names, and every synchronization error swallowed.

• SQL Server (Free): the filter and aggregate builders refuse what they cannot read. An operator they did not know became 1=1 (the condition vanished) or 1=0 (no rows - and every row under $not); an unknown comparison became =; a value that was not a number became 0; an aggregate they could not compile became a NULL column. They now fail through one helper, dbo.pvt_fail, with a message that starts with "redb:", where the PostgreSQL module raises. LINQ does not produce these shapes; JSON filters sent directly do.

• The SQL modules' smoke runners run in the integration suite (PostgresModuleSmokeTests, MsSqlModuleSmokeTests). They were run by hand only.

• PostgreSQL Pro: the pivot takes a scalar field with max() instead of (array_agg(...))[1]. The array per object and per field kept the planner on a sorted GroupAggregate; max() lets it hash-aggregate. A filtered, sorted page over 200 000 objects went from 1.1-1.4 s to 0.84-0.98 s. The FILTER leaves one row per object, so the value is the same. PostgreSQL 14 has no max() for every type: bool fields take bool_or, Guid and byte[] fields keep array_agg. One helper (PvtPick) now renders this for every Pro PostgreSQL query shape (flat, tree, aggregate, grouping, window, grouped window, array grouping) instead of 26 copies.

Fixed

• Pro (all three providers): ToAggregateSqlStringAsync showed the aggregate without the query's Where. The preview built the SQL with no filter while AggregateAsync runs with it, so the preview of a filtered sum was a sum over the whole scheme. It now passes the same filter. Only the preview was wrong; results were not.
• SQL Server (Free), JSON filters, found by the smoke runner once it ran: $arrayAt read its operand as the index and never compared the value - it now takes {"index":N,"value":V} as PostgreSQL does; $arrayCountLte was spelled $arraycountle and matched nothing; $ilike on a field was missing; {"Dict.ContainsKey":"key"} with a bare string key was never recognised. Each returned no rows without an error. SQL Server module version 0.2.26.
• Configuration copies lost five settings. Clone did not copy AutoApplyDatabaseUpgrades, StringCollation, EnablePvtPrefilter, PropsSaveStrategy and DefaultCheckPermissionsOnQuery. The auto-fix of an invalid configuration (GetValidatedRedbServiceConfiguration without throwing) returned such a copy, so it could switch automatic schema upgrades back on for an operator who had turned them off.
• ApplyTemporary left its change behind. The builder form edited the live configuration before taking the snapshot meant to undo it, so the scope ended with the temporary values in place. The configuration form applied and restored fourteen settings out of thirty-six. Both apply and restore every behaviour setting now, and never touch the connection string or the cache domain.
• Pro: a stored collection element that did not convert to the element type was lost without a word. The same failure had three outcomes, chosen by the shape of the collection: a dictionary entry vanished, an array element became the type's default (0), a list element was skipped. Loading now fails with the value, the target type and the original error.
• SQLite: a column value the row mapper could not convert left the property at its default. Two silent catch blocks made the row read as if the column were NULL. It fails now, naming the column, the value and the property. Conversions use the invariant culture (a decimal text like 1.5 was parsed with the current one).
• Tree projections (TreeQueryableBase.Select): Take / Skip / Distinct after Where / OrderBy. Where and OrderBy ran in memory after the projection while Take and Skip went to SQL before it, so the page was cut from the unfiltered, unsorted nodes; Distinct went to the source query, where every node is distinct. They now run in call order after the projection, as the flat projection has done since S-4.
• Free: DistinctByRedb / DistinctBy on a tree query returned every node. The flat query passed the distinct key to pvt_build_query_sql; the three Free tree providers passed none. They pass it now. The SQL builders then had to honour it in the tree shape too: SQL Server ignored the key in the tree branch without props fields, and the SQLite native extension ignored it in the wide shape (a tree without props fields, or a filter with an absence check). SQL Server module version 0.2.24, SQLite extension version 0.6.7 - the SQLite native library is rebuilt for Windows x64 and Linux x64/arm64.
• Pro: DistinctByRedb / DistinctBy on a tree query.
  • SQLite Pro ignored the distinct key on a tree and returned every node: the key was computed and never put into the SQL. The tree now ranks rows with ROW_NUMBER() as the flat query does.
  • CountAsync of a distinct tree query was wrong on all three Pro providers. PostgreSQL counted every node (COUNT(DISTINCT o._id) - the ids are distinct whatever the key is); SQL Server and SQLite looked for a PostgreSQL DISTINCT ON, did not find it, and returned the first column of the first row - an object id. The count is now the number of distinct keys, and a count that cannot find the distinct query refuses.
• SQL Server (Free): an unknown nested field resolved to its parent. T-SQL keeps a variable's old value when SELECT @v = ... finds no row, so dbo.pvt_resolve_field_path returned the parent structure for a child the scheme does not have (Contacts[].NoSuchField became the Contacts array), and a filter, sort or grouping on that path read the wrong structure. The dictionary child and the list-item accessor had the same trap.
• SQL Server (Free): the array grouping skipped a key or aggregate field the item does not have. The grouping ran on the remaining keys, the aggregate vanished from the result, and with no key left the flat list of items came back instead of groups. Such a request is refused now, as is an unknown aggregate function.
• Pro: HAVING constants. An array or object in $const was bound as its raw JSON text and compared as a string; it is refused now. The unreachable fallback operator = of the translator is a refusal too.
• SQL Server module version 0.2.26: the functions are reinstalled on the first start.

Fixed

• A window frame on Pro reached SQL as CURRENT ROW whatever it said. The core writes the frame as {type, start:{kind, offset}, end:{kind, offset}}; the three Pro providers read another shape (StartType, EndType at the top level) and found none of it, so Frame.Rows().Preceding(1) or a frame over the whole partition became ROWS BETWEEN CURRENT ROW AND CURRENT ROW: a running sum returned the current row, with no error. The tests passed, because they compared with >=, which a one-row frame also satisfies. One compiler in redb.Core.Pro now serves PostgreSQL, SQL Server and SQLite, reads the shape the core writes, and refuses a bound it does not understand instead of replacing it with CURRENT ROW. The Free providers were not affected.
• The permission cache answered for the wrong database. It is shared by the process and was keyed by user and object only, while ids are per database: two databases hand out the same ids in the same order, and the system admin is id 1 in every one. In a process that serves several databases (Tsak with named instances), a permission worked out in one was served for another - with the default DefaultCheckPermissionsOnDelete = true, that decided whether a delete went through. The key now starts with the service's cache domain, and invalidation touches that database's entries only. Other nodes of a cluster still keep an entry until its five-minute lifetime runs out.
• redb.Export: an import is one transaction, checks the file is whole, and restores ids correctly.
  • On SQL Server the id sequence came back one step behind: the exporter reads the last id handed out, and RESTART WITH names the next one, so the first object saved after an import took an id an imported row already had. It now restarts one past it, as PostgreSQL and SQLite already did.
  • Rows went into the target tables batch by batch as they were read, the constraints and triggers came back only after a successful run, and nothing rolled back: an import that stopped half-way left a half-filled database with its integrity switched off - and, with cleaning, an emptied one. The whole import, cleaning included, now runs in one transaction that commits at the end or rolls back.
  • A file cut short imported up to the cut and reported success. The footer the exporter writes lists how many rows of each kind it wrote; the import now requires it and compares every count before the commit, so a short or damaged file changes nothing.
  • _schemes._tags, _structures._tags and _structures._unique_scope were not exported: after a round trip the markers were gone and every collection key fell back to the default scope. They travel now; files written before this change import as before, with those columns empty.
  • The cleaning step no longer swallows errors: SQL Server decides between TRUNCATE and DELETE from the catalog instead of trying and ignoring the failure, and SQLite skips a table it does not have by looking, not by catching - a lock or a missing permission used to leave a table full and the import went on mixing old and new rows.
  • IDataProvider gained BeginImportAsync, CommitImportAsync and AbortImportAsync.
• The documentation of RedbServiceConfiguration.EnablePvtPrefilter said the prefilter was PostgreSQL only. It is implemented by all three Pro providers - PostgreSQL, SQL Server and SQLite - and has been for several releases; the sentence was left behind when the prefilter reached the other two.
• Tree queries and groupings that answered wrong without an error.
  • A window frame on a tree query (Pro) was dropped: the tree read the frame in a shape the core does not write, found nothing, and every frame became ROWS UNBOUNDED PRECEDING - a sum over the whole tree came back as a running total. The tree now uses the same frame compiler as the flat query.
  • TreeQuery(...).GroupByArray(...).Having(...) without a Where lost the HAVING and returned every group.
  • A composite grouping key with a member that is not a field (Initial = e.FirstName.Substring(0, 1), Length = c.Value.Length) was skipped, or read as a field path it is not, and the grouping ran on other keys. Tree, array and tree-window groupings now refuse such a key with NotSupportedException naming the member, as the flat grouping already did.
  • Having on a tree grouping changed the grouping itself, so a second query branched from it inherited the first one's condition. It returns a copy now, as the flat grouping does.
  • WithMaxDepth on a tree query dropped the props depth, lazy references, projection and distinct settings set before it. It keeps every setting now.
• SQL Server (Free): GroupBy(...).Having(...) ignored the HAVING and returned every group. The provider passed NULL for it and dbo.pvt_build_groupby_sql never emitted one. It compiles HAVING now, aggregates through the same builder as the SELECT list; a HAVING shape it does not know makes the call fail instead of being dropped. Tree groupings on SQL Server Free take the same path and are fixed with it. The HAVING test suite now runs on SQL Server Free too - it ran on the other five hosts only, which is how this went unseen.
• SQL Server (Free): an array grouping that aggregated one item field twice failed (Min(c => c.Value) and Max(c => c.Value) in one select: "Invalid column name 'Value'"). The second aggregate reuses the joined column now.
• SQL Server (Free): HAVING of an array grouping on an item field failed, and an unknown HAVING node was dropped. GroupByArray(...).Having(g => Agg.Max(g, c => c.Value) == ...) compiled the field as [Value], a column the query does not have, so SQL Server refused it. A HAVING node the translator did not know became 1=1 and every group came back. The translator now reads item fields through the joined columns (a field only the HAVING aggregates gets its own join) and refuses any shape it does not know.
• SQL Server module version 0.2.21: the functions are reinstalled on the first start.

Added

• Storage maintenance reports what a DBA needs, and marks what must never be dropped. The maintenance facade grew on the request of redb.Tsak (2026-09-21), which builds a "what is going on in the database" page: an operator reads it and hands the findings to a DBA. Read-only by design - VACUUM, REINDEX and counter resets are deliberately not offered, because a button that locks a production table must not be one click away in a dashboard.
  • IndexStatistics.Schema: the schema of the table the index belongs to (null on SQLite). Two tables of the same name in different schemas used to be one indistinguishable row, so any grouping by table lied.
  • IndexStatistics.Columns and IncludedColumns: the key columns in index order, and on SQL Server the carried ones separately - without them a covering index is indistinguishable from a composite one, and "which fields is it on?" had no answer.
  • IndexStatistics.IsSystemCritical with CriticalReason, plus IsPrimaryKey, IsUniqueConstraint, IsClustered, BacksForeignKey and IsRedbOwned: an index of the redb schema, or one backing a key or a uniqueness constraint, must survive whatever its usage counters say. Some of them serve uniqueness or a key check and are never scanned, which is exactly how a well-meant cleanup removes them. The reason travels along, so a page can say which of the three it is: redb metadata, redb security, redb data.
  • IMaintenanceProvider.GetTableStatsAsync(): size, row estimate, the size of the table's indexes, when statistics were last refreshed, and on PostgreSQL dead rows and the last vacuum.
  • IMaintenanceProvider.GetStatisticsWindowAsync(): since when the usage counters have been counting (the last statistics reset, or the start of the instance) and whether the node is a replica. Without it "this index served no read" says nothing.
  • IMaintenanceProvider.AnalyzeTableAsync(table, schema): refreshes the planner statistics of one table instead of the whole database, which runs for minutes on a real one. Every engine supports it, SQLite included. The name is checked against the catalogs and quoted by the dialect: it comes from a dashboard, and an identifier cannot be a query parameter.

Fixed

• GetTableStatsAsync() on a SQLite database nobody has analysed yet. sqlite_stat1 does not exist until the first ANALYZE, and a statement naming a missing table does not even prepare, so both forms of the query failed - including the size-less one, which named it as well. A fresh database is the state every quick-start image starts in, so a storage page answered an error while the ANALYZE button that would have fixed it sat on that same page (reported by redb.Tsak, 2026-09-21). The dialect now lists the forms of the query in decreasing capability - with dbstat and sqlite_stat1, with sqlite_stat1 alone, with dbstat alone, with neither - and the first that runs wins. On a database never analysed the answer is what the engine knows: EstimatedRows null and HasStatistics false, which is exactly what that flag exists to say.

Added

• IRedbScopeSource, implemented by every IRedbService: CreateScope() opens a scope of the container the service came from and hands over its service of the same database; the holder disposes the scope. CanCreateScope says whether there is a container. For code that holds one service and needs one per unit of work (redb.Route calls outside an exchange). A container whose scopes resolve another database is refused.
• IRedbService.BeginAccess(): makes a service the scope lazy loads run on, for a block (UI event handlers, callbacks outside the flow that resolved the service). See "Lazy loads run on the reader's scope" under Fixed.
• IRedbService.LoadLinkedObjectsAsync(items): loads the linked objects of many list items in one batch on the service's connection and publishes them on the items.
• RedbServiceConfiguration.LazyLoadWithoutScope (Refuse by default, or FreshScope): what a lazy load does when no live redb scope reads it.
• ILazyPropsLoader.CacheDomain (a default interface member): the database a scope-bound loader reads.
• The native SQLite extension is versioned like the PostgreSQL and SQL Server modules: InitializeAsync asks the loaded redbsqlite library for pvt_module_version() and refuses a build of another version, naming the file (SqliteDialect.Query_PvtRequiredVersion(), now 0.6.6). A stale library next to the application loaded silently and answered in an old shape.

Fixed

• The README of the redb.Templates package described the options of an older template: --db without sqlite, and defaults of PostgreSQL and Free. The template defaults to SQLite and Pro; the README now says so and lists what the generated app does.

• RedbSchemaOutdatedException named a command the redb tool does not have (redb schema upgrade-script). It now names redb schema --upgrade --provider <name>.

• Work inside a TransactionScope now belongs to that transaction on MSSQL, PostgreSQL and SQLite (a redb.Route .Transacted() block among others). Inside a scope redb used to write past the transaction or fail:

  • MSSQL: a speculative ROLLBACK sent right after a connection opened detached it from the scope. Raw SQL through redb.Context autocommitted and survived an abandoned scope, and SaveAsync failed with "Cannot issue SAVE TRANSACTION when there is no active transaction".
  • PostgreSQL: a connection opened before the scope stayed out of it (25P01 SAVEPOINT can only be used in transaction blocks), and a second connection (the key generator, another DI scope) aborted the commit (55000 prepared transactions are disabled).
  • SQLite: the driver never takes part in System.Transactions, so everything autocommitted without an error.

  Now the transaction holds the connection. Every redb connection wrapper of the same database, in every DI scope, runs its commands on one connection per ambient transaction (AmbientConnectionRegistry). MSSQL and PostgreSQL open it inside the transaction and enlist. On SQLite redb runs BEGIN IMMEDIATE on it and commits or rolls it back with the scope, so the database write lock is held until the scope ends. Inside a scope the key generators take keys on that connection (a rollback leaves a gap in the sequence, never a duplicate), and the background key refill no longer inherits the caller's transaction. A lazy load runs on the reader's scope and so inside its transaction; only a load opened by LazyLoadWithoutScope = FreshScope reads committed state outside it. The speculative ROLLBACK is gone: the SqlClient pool resets a returned session itself.

  Behaviour to know:

  • Parallel branches in one transaction are not supported. Two commands at the same time on the transaction's connection (dependent clones, a parallel split) are refused with InvalidOperationException. Run the branches sequentially, or give each branch a transaction of its own.
  • A command after the transaction ended (rolled back because a branch failed, or timed out) is refused; it never runs outside the transaction.
  • An explicit redb transaction begun before the scope keeps its own connection, and BeginTransactionAsync inside a scope is still refused.
  • Two redb configurations of the same database that differ in connection parameters or session settings (lazy references, collation, case folding) do not share a transaction's connection: the first command of the second one is refused with InvalidOperationException, instead of running on a connection set up with the other configuration's settings. A connector with its own connection (for example redb.Route's sql:) to the same database in the same transaction is a second connection: SQL Server refuses it, PostgreSQL aborts the commit, SQLite writes outside the transaction. Raw SQL that belongs to the transaction goes through redb.Context.
  • Stores that resolve a DI scope of their own now take part in the caller's TransactionScope.

• SQLite: disposing scoped services between TransactionScope.Complete() and Dispose() no longer throws "The current TransactionScope is already complete".

• DeadlockRetryHelper no longer retries inside an ambient TransactionScope. A deadlock victim's transaction is already rolled back by the server (SQL Server 1205, PostgreSQL 40P01), so running the command again inside it failed with a second error (25P02, an aborted transaction) that replaced the deadlock itself. Inside an ambient transaction the original deadlock now leaves at once and the unit of work (a route's retry, the caller) runs the whole transaction again. Outside one, and under TransactionScopeOption.Suppress, the retry works as before.

• Loading an object no longer loads the objects behind its list items. RedbListItem.Object is lazy: reading it is a database load. Several walks over a loaded graph read every property of the list items they met, so each linked list item (IdObject set) in Props cost a load of its object that nobody asked for, and on Pro SQLite the load failed ("Error lazy loading Object for ListItem"). The walks were Pro loads of Props with references (substituting the loaded references, nulling references to deleted objects, completing lazy reference stubs) and the props-cache check for unsaved edits in nested objects on every cache hit (Free and Pro, point, bulk and sync loads). A list item is now a leaf for every such walk, in one rule shared by all of them (LazyReferenceInstaller.IsWalkLeaf). Reading Object explicitly loads it as before.

• Pro: the synchronous Load<T> builds the same object as LoadAsync, on the calling thread. It used to fall back to the Free in-database JSON builder (get_object_json): on Pro SQLite, which has no such function, Load<T> and a first read of RedbListItem.Object failed ("no such function"; hidden whenever a Free SQLite registration in the same process had loaded the native extension), and on Pro MSSQL/PostgreSQL the result differed from the async load (list items lost their IdObject). The synchronous Props getter of a lazy reference stub ran its load through Task.Run, holding a thread-pool thread per touch on top of the blocked caller. Both now run the Pro materializer itself, with every database call synchronous on the calling thread: no Task.Run, no Parallel.ForEach, and a load that would go asynchronous is refused instead of blocked on. New synchronous members: IRedbConnection/IRedbContext Query<T> and Execute, ISchemeSyncProvider.GetSchemeById, GlobalMetadataCache.ResolveClrType.

• Free: list items in Props keep IdList and IdObject. The in-database JSON builders (PostgreSQL module 0.7.11, MSSQL module 0.2.16, SQLite native extension) wrote a list item with the key idList and without id_object, while the model reads id_list and id_object. Every Free load returned the list items in Props with IdList = 0 and IdObject = null, so RedbListItem.Object had nothing to load. PostgreSQL and SQLite also built the whole linked object for every such item, under a key the deserializer ignores.

  Behaviour to know: the raw object JSON (LoadJsonAsync, a direct get_object_json call) now writes a list item as {"id", "id_list", "value", "alias", "id_object"}. idList is renamed and the nested object is gone; load the linked object by id_object. The SQLite extension must be the rebuilt one.

• MSSQL Free: a reference to an object in the trash stays in its collection as null (module 0.2.17). An array of references lost that element ([kept, gone] loaded as [kept], shifting every index after it) and a dictionary of references lost the key, because the aggregate skipped the NULL returned for the trashed target. PostgreSQL, SQLite and Pro already returned null in its place; MSSQL now does too.

• A list item's linked object loads typed on a node that has not cached its scheme yet. On a fresh process or another cluster node, RedbListItem.Object and GetObjectAsync took the CLR type from the metadata cache only and, on a miss, returned an untyped RedbObject<object> built by get_object_json (on Pro SQLite, which has no such function, the load failed). The scheme is now resolved by its id, as the hand-out preload already did. RedbServiceBase implements ISchemeSyncProvider.GetSchemeById.

• SQLite Free: a list item's linked object of a scheme without a CLR type loads. The untyped load sent the PostgreSQL text of the get_object_json call, ::text cast included, and SQLite failed to parse it. The linked-object loaders now take that SQL from the provider's dialect, like every other load.

• Loads no longer read [RedbIgnore] properties or swallow a getter's exception. The walks over a loaded graph (lazy-loader installation, the props-cache collector and its check for unsaved edits, the Pro reference substitution, the lazy reference stub collection) read every public property, including [RedbIgnore] ones, and ignored whatever a getter threw; the Props hash wrote an empty string for such a property. They now walk the property set the scheme and the save use: public, not an indexer, not [RedbIgnore].

  Behaviour to know: a getter of a stored property that throws now fails the load and the hash, as it already failed the save. Mark a computed property that is not data with [RedbIgnore].

• A failed command no longer leaves a transaction behind on its connection (trash review). When the SQL text of a command opened a transaction itself and then failed (a SAVEPOINT or BEGIN followed by an error, or a command timeout or cancel inside BEGIN TRANSACTION), nothing ever ended that transaction. On SQLite the pooled handle kept the database write lock, and every writer waited out its busy timeout ("database is locked") until the pool happened to hand that handle out again. On MSSQL the scope's later statements ran inside it and were rolled back with it: a save reported success and its row was gone. On PostgreSQL every later command of the scope failed with 25P02. The PostgreSQL, MSSQL and SQLite connection wrappers now roll such a transaction back before the exception leaves, unless a transaction of the wrapper or an ambient TransactionScope owns the connection; the original exception always propagates. SQLite also rolls back an unowned transaction before a handle returns to the pool.

• Soft delete on MSSQL: sp_mark_for_deletion and sp_purge_trash run with SET XACT_ABORT ON and open a transaction only when the caller has none (module 0.2.15). A timeout inside the mark used to leave @@TRANCOUNT = 1 on the session. On SQLite the mark and purge batches no longer open a savepoint in their own text. On every provider the mark and each purge batch run inside one transaction, joining the caller's.

• Purging a trash container whose objects are referenced (PostgreSQL module 0.7.10, MSSQL module 0.2.15, SQLite dialect). A RedbObject<T> reference is a foreign key with no ON DELETE action, so a single referenced object failed the whole batch, the container stayed running and the background worker retried it every 30 minutes, forever. Now a reference held by an object that is itself in the trash is removed together with the purge, whatever order the containers are purged in. An object referenced by a live object is skipped and its reference is never nulled; everything else is purged, the container is marked failed (no longer claimed automatically), and PurgeTrashAsync throws the new RedbObjectReferencedException naming the referenced and the referencing objects. Remove or re-point those references, then purge the container again.

• Background deletion worker: a claim that fails no longer ends the poll cycle for every container after it, the scan and each claim use short scopes of their own, and a container that ends failed is logged as a warning and not retried.

• An empty database is named as such at start-up. InitializeAsync() without ensureCreated: true on a database that has no redb schema used to fail on the first start-up query with a raw driver error (relation "_structures" does not exist, Cannot find the object "dbo._structures", no such table: _schemes) that said nothing about how to proceed. It now throws RedbSchemaMissingException, whose message names the two ways out - InitializeAsync(ensureCreated: true) / RedbServiceConfiguration.EnsureCreated = true, or the script from GetSchemaScript() for the schema owner - and reminds that an unexpectedly empty database is usually a wrong connection string. Schema creation stays opt-in by design. Pinned on all three providers against a throwaway empty database.

• Props cache under load. With EnablePropsCache a busy process slowed down several times while its idle database connections grew. Three causes:

  • Every cache hit checked the object hash and walked the object's loaded graph under one process-wide lock, so concurrent loads waited for each other with their connections open. The check now runs outside the lock.
  • An insert into a full cache sorted all entries under the write lock to evict one of them. A full cache now evicts the least recently used tenth of PropsCacheMaxSize at once, without sorting.
  • An object cached again kept the lifetime of its first insert: once PropsCacheTtl had passed, an object reloaded periodically missed on every load. A re-cached object now starts a new lifetime, and an expired entry is dropped when it is read.

  The service now passes its logger to the cache. The cache warns, at most once per 10 seconds, when the objects in use do not fit PropsCacheMaxSize, when checking a hit takes 50 ms or more, and when 100 lookups find a live entry and serve none (typically a read model that does not reproduce the saved graph). The detached list-item load warning now counts loads per 10 seconds (200) instead of concurrent loads (20): loads that run one at a time drain the connection pool as well.

  Behaviour to know: the props cache no longer applies per-user quotas. UserConfigurationProps.PropsCacheSize is still stored and merged, but it does not limit the cache; the only limit is PropsCacheMaxSize.

• SQLite: dbVersion, GetDbVersionAsync() and dbSize work. The SQLite service sent the PostgreSQL text (version(), pg_database_size(current_database())) and failed with "no such function". It now returns sqlite_version() and the database file size in bytes (page_count * page_size), Free and Pro.

• dbSize is in bytes on every provider. The contract said megabytes; PostgreSQL returned bytes and MSSQL kilobytes. The contract now says bytes, and MSSQL multiplies its 8 KB pages by 8192.

  Behaviour to know: on MSSQL dbSize is now 1024 times larger than before.

• A list of references, List<RedbObject<T>>, is saved the way an array of them is. The save recognised arrays only and skipped the elements of a list:

  • a new object in the list was never saved, and the parent's save failed on the foreign key;
  • an edit to a loaded object in the list was silently lost when the parent was saved;
  • a reference by id got no hash, so the parent's stored hash never matched the loaded one and the object missed the props cache on every load.

  Any generic collection of RedbObject elements now counts, like an array. AddNewObjectsAsync also resolves the hashes of references by id before hashing, as SaveAsync does: the objects it created with references missed the props cache for the same reason.

  Behaviour to know: saving a parent now saves the loaded objects in its lists too, as it already did for arrays and single references.

• Lazy loads run on the reader's scope: no hidden connections. RedbListItem.Object and the Props of a reference stub used to open a fresh DI scope, and with it a pooled connection, for every read wherever the item or stub carried no loader of the right scope. That covered every list item materialized by Pro (the Pro service took a second IListProvider instance from DI, one without loaders) or from Free JSON, every reference inside an object served from the props cache, and every read after the loading scope ended. A data object now owns no connection: such a load runs on the live redb scope of whoever reads it (the scope that resolved IRedbService in the current flow, or a block in using (redb.BeginAccess())), on that scope's connection and transaction. Where no scope is current for the reader (a test fixture, a service kept in a field, a UI event handler), the scope that materialized the object or item answers, as long as it lives. An instance shared by a cache (the props cache, the list cache) is never bound to that scope, and neither is anything it loads or already carries.

  Behaviour to know:

  • When no scope is current for the reader and the materializing scope has ended, or when a shared instance of a cache is read with no scope current, the read throws RedbLazyLoadScopeEndedException, which names the ways out. RedbServiceConfiguration.LazyLoadWithoutScope = FreshScope opens a scope per such load instead, with a rate warning.
  • Code that reads objects from a cache outside the flow that resolved the service (UI event handlers in Blazor Server, WebAssembly, MAUI; callbacks) wraps those reads in using (redb.BeginAccess()).
  • An object from the props cache, or an item from the list cache, read inside a transaction sees that transaction's data and does not keep it, because the write behind it may roll back. Before, the read went to a separate connection and saw committed state.
  • Two reads of lazy data at the same time on one scope are refused, like any two concurrent commands on a scope.
  • An IListProvider injected from DI is now the service's own ListProvider.

• A service resolved from the root provider lends lazy loads a fresh scope, not its connection. Such a captive service (provider.GetRequiredService<IRedbService>() in a Program.cs, a service kept for the life of the process) is the reader for every flow that touches an object of the props cache or a list of the list cache, and parallel lazy loads of those instances all ran on its one connection: the second was refused as a concurrent command. Outside a transaction such a load now runs on a service of a fresh scope of the same container, on a pooled connection; what it reads is committed state, which a shared instance keeps. Inside the captive service's transaction the connection is the transaction, and a lazy load stays on it and reads what the transaction wrote, as before. A high rate of such loads is reported, as for LazyLoadWithoutScope = FreshScope. What a lent scope materializes belongs to the captive reader: the stubs under it name the captive service as their origin, not the scope that ended with the load, so they load the same way. RedbServiceProviders.IsRoot(serviceProvider) tells the root provider of a Microsoft DI container from a scope's.

• Pro honours the Props depth of a query. WithPropsDepth(n) on Query<T>() and TreeQuery<T>() was ignored by the Pro providers of all three databases: Props loaded to DefaultMaxTreeDepth, so references meant to stay stubs came back loaded, with the whole graph behind them.

• Tree nodes keep ValueUnique. Tree queries on Free returned nodes whose ValueUnique was null: the conversion of an object to a tree node dropped the key, and on PostgreSQL and SQL Server the tree query did not even select the column.

• A reference without a hash loads its Props. A reference built in code (new RedbObject<T> { id = ... }) passed to LoadReferencesAsync stayed without Props on Free while the props cache was on: the cache had no hash to match it by, and the object was dropped from the load. On Pro the same reference got empty Props marked as loaded, because Props are assembled by scheme and the reference carried none; its scheme is now read from the database.

• Regex.IsMatch and Regex.Replace in filters on SQL Server and SQLite. On SQL Server, Free and Pro, Regex.IsMatch was dropped from the query without a word and every row came back; Regex.Replace matched nothing on Free and was refused on Pro. They now translate to REGEXP_LIKE and REGEXP_REPLACE. On SQLite both failed: the Pro builder emitted PostgreSQL operators, and the Free extension refused them. The provider now registers redb_regexp, redb_regexp_i and redb_regexp_replace (.NET Regex) on every connection it opens, and both editions use them.

  Behaviour to know:

  • SQL Server needs version 2025 with compatibility level 170 for these functions; an older server refuses such a query by the function name. The SQL Server module version is 0.2.18.
  • A pattern runs on the engine of the database: POSIX on PostgreSQL, RE2 on SQL Server, .NET on SQLite.
  • The SQLite Free extension must be rebuilt for every platform.

• A tree node is served from the props cache. An object saved as TreeRedbObject<T> - every CreateChildAsync, every tree node saved directly - stored a header-only hash: the save recognised the exact generic type RedbObject<> and nothing derived from it, so the hash the loaded object recomputes (header and Props) never matched the stored one and every cache probe of such an object was a miss. The same test kept a tree node out of the cache after its save and out of the scheme auto-detection.

  Behaviour to know: a node saved before this fix carries the old hash until its next save; until then it loads from the database as before, and the next save stores the hash the cache matches.

• A moved object is not served from the props cache with its old parent. MoveObjectAsync updates the parent outside the save path and drops the object's hash in the database, but left the cached copy in place; with SkipHashValidationOnCacheCheck a load never asks the database and answered with the old parent until the entry expired.

• Loading objects by a list of ids asks the database once, not once per id, and uses the props cache under SkipHashValidationOnCacheCheck. The batch used to issue one SELECT id, hash, scheme per id before the cache probe, and with the flag it skipped the cache altogether and rematerialized every object. One query now resolves the hashes and schemes of the whole batch, in both modes. This is the road of the list-item preload and of LoadLinkedObjectsAsync.

• The object hash sees sub-second changes and does not depend on the process culture. The canon of a Props value was ToString(): a DateTime or DateTimeOffset lost its sub-second digits, and a double, decimal, DateOnly or TimeOnly took the decimal separator and date format of the current culture. Under the ChangeTracking save an object whose hash equals the stored one is not written, so a temporal property changed within the same second - a heartbeat, a "last seen" - was silently lost; and two nodes with different cultures hashed one object differently. The canon is now invariant: temporal values in UTC at millisecond precision (the precision every database keeps), numbers in the invariant culture. A DateTime hashes by its clock reading whatever its Kind, exactly as it is stored.

  Behaviour to know: the hash of every object with temporal or floating-point Props changes once. The first save of such an object after the upgrade runs the full diff (the ChangeTracking shortcut does not apply) and stores the new hash; the first props-cache probe of it misses. A change below one millisecond is not a change: the databases do not keep it.

• SQLite: dates before 1899-12-30 and the temporal MinValues round-trip. The REAL Julian day of a DateTime, DateTimeOffset or DateOnly was computed through the OLE automation date (ToOADate), which is not linear: its zero stands for DateTime.MinValue, so a default date came back as 1899-12-30, and a day before its epoch is encoded as sign and magnitude, so any time of day before 1899-12-30 moved by a day - on the way in through the Pro writer and every filter value, and on the way out for rows the native extension wrote through SQLite's own julianday(). The day count is now linear in the tick count, truncated to the millisecond; for every instant from 1899-12-30 on it is bit for bit the number stored before, so existing rows and equality filters keep matching.

• PostgreSQL: a trash purge no longer fails the container when another purger deleted its batch. purge_trash marked the container 'failed' when a batch deleted nothing while objects remained, reading it as "every remaining object is referenced by a live object". A batch chosen here and deleted meanwhile by a concurrent purger - the background worker beside a caller's PurgeTrashAsync, another node - failed the container with nothing blocking it, the worker stopped claiming it, and the caller got RedbObjectReferencedException naming no referrer. 'failed' now means an empty batch; a batch that deleted nothing leaves the container 'running', and the purge goes on with the next one. PostgreSQL module 0.7.12, applied by InitializeAsync like every module upgrade. SQL Server counts the batch it chose and SQLite chooses and deletes under the write lock, so neither saw the race.

• SQLite: a finished trash container is removed. PostgreSQL and SQL Server remove the container in the purge function once it holds no objects; the SQLite purge statement ends with its result row and could not, so every completed container stayed in _objects for good, and GetDeletionProgressAsync kept answering 'completed' for it where the other providers answer null. The purge now removes it after the last batch.

• RedbListItem.GetObjectAsync(cancellationToken): the token reaches the load. It was accepted and dropped on the way to the query, so a cancelled reader still ran the scheme lookup and the load.

• A scheme without a CLR type is resolved once per cache domain. Reading the object behind a list item of such a scheme loaded the scheme again on every read: a list of 200 items was 200 scheme queries.

• The props cache no longer takes a process-wide lock on every hit for the "found but never served" diagnostic; its counters are lock-free like the other diagnostics.

• Two hosts of one database that differ in RedbServiceConfiguration.LazyLoadWithoutScope are reported with a warning, once per database. The registration of the most recently constructed service wins, so which policy a lazy load with no live scope got depended on which host constructed a service last.

• An edit made inside a transaction on the lazy reference of a loaded object is saved; the caches publish committed state only. A props-cache Set marked the loaded graph shared at once, and a shared instance does not keep what one transaction saw - so inside a transaction the writer's own loaded object never kept its lazy references: root.Props.Next.Props.Label = ...; SaveAsync(root.Props.Next) saved a fresh reload and the edit was lost, and every read of item.Object of a cached list was a query. A Set inside a transaction (an explicit redb transaction or an ambient TransactionScope) now waits for its commit; until then the instances are the reader's own, and what a rolled-back transaction loaded never reaches the cache. Behaviour to know: inside one transaction the same object loaded twice is materialized twice - the cache answers only after the commit.

• A saved object served from the cache loads its hand-made references. The save cached the caller's graph as it was, and a reference written as new RedbObject<T> { id = x } carried no loader: a load served from the cache returned that very stub, and its Props came back null - no query, no exception. The save now gives the stubs of the saved graph the loader of its database before caching, as a load does.

• A saved graph that is not a tree hashes references before their parents; a new object referenced twice is saved once. A parent's hash carries "id:hash" of every reference, and the save hashed in the reverse of a pre-order walk that collects a target shared by two parents once, under the first: the second parent stored the target's stale hash for ever - a props-cache miss on every load. The same walk never deduplicated a new object: one instance referenced from two places was collected twice, given an id twice and inserted twice.

• The connection of an ambient transaction opens under a lock per transaction and database. One process-wide lock held the first open of every other transaction, on every database, behind a SQLite BEGIN IMMEDIATE waiting for its write lock.

• The save answers "is this a reference / a collection of references / a business class" once per type instead of reflecting over the type's interfaces for every property of every object, and caching a loaded graph no longer walks every nested object's subtree again to mark it shared - the root's Set marked the whole graph.

• Saving a reference whose properties were never loaded is refused with RedbUnloadedReferenceException. SaveAsync(root.Props.Next) where Next is a stub whose lazy load the getter did not keep (a shared instance inside a transaction), or a hand-written new RedbObject<T> { id = x }, saved whatever a fresh load returned - the caller's edits were lost silently - and cached the unloaded stub, whose validation on the next load was a lazy load inside the cache probe: a deadlock with the load that probes. The exception names the ways out: load the object (redb.LoadAsync(id), redb.LoadReferencesAsync(parent, p => p.Reference)), edit and save the loaded one. Reading the Props of such a reference still answers null: plain System.Text.Json serialization of a graph reads the getter, and an exception there would fail every API response carrying a hand-made reference. A saved graph gives its hand-made references their loader, with or without the props cache. An object without Props - a scheme with no properties (a flag, a counter: the object lives in its base fields), an object saved with Props = null - is a loaded object, not a reference: what redb materializes as a root (LoadAsync, a query, a tree) is loaded by definition, on every provider; the refusal applies to a stub redb attached a lazy loader to (a depth boundary, a cache) that is still unloaded.

• The props cache never holds or serves an unloaded instance: a save caches loaded objects only, and a cache hit whose instance has no loaded Props is not served.

• A shared instance keeps what a transaction loads while the transaction has written nothing, and forgets it if the transaction rolls back. The rule "a shared instance does not keep what one transaction saw" guarded a narrow hazard - a transaction's own uncommitted write read back through a shared parent - at the price of the writer's edits in every ordinary flow: an object served from the cache, or loaded before the transaction, edited through its lazy reference inside the transaction (root.Props.Next.Props.Label = ...; SaveAsync(root.Props.Next)) saved a fresh reload. While the transaction has written nothing, what its connection reads is committed state, so the shared instance keeps it - stubs and list items alike - and drops it if the transaction ends without a commit. Once the transaction has written (a save, a delete, a tree move, a raw Context.ExecuteAsync, a bulk operation, a soft delete or purge), what it reads may be its own uncommitted work: the shared instance keeps nothing of it, and saving such a stub is refused with RedbUnloadedReferenceException instead of writing a fresh reload.

Changed

• The redb-console template and redb.Examples resolve IRedbService from a scope (provider.CreateAsyncScope()) instead of from the container root: one service is one connection, and a scope per unit of work is the shape that carries over to hosts with many flows. A console works either way.

• Microsoft.Data.SqlClient 7.0.3 (was 5.2.2) in redb.MSSql and redb.Export; redb.MSSql.Pro gets it through redb.MSSql. The 7.0 line supports .NET 8 and newer and ships net8.0 and net9.0 builds (net10.0 uses the net9.0 one). redb.Route, redb.Tsak and redb.Identity build and test on the same driver version.

  Behaviour to know:

  • Microsoft Entra ID authentication (Authentication=Active Directory ... in the connection string) is no longer in the driver package. An application that uses it adds Microsoft.Data.SqlClient.Extensions.Azure. The driver no longer brings Azure.Core, Azure.Identity and Microsoft.Identity.Client. redb does not use Entra ID itself.
  • The driver lines 5.x and 6.x are no longer supported. An application that pins Microsoft.Data.SqlClient below 7.0.3 gets a NU1605 package downgrade error and has to raise the pin.
  • The driver needs Microsoft.IdentityModel.* and System.IdentityModel.Tokens.Jwt 8.16.0 or newer. A lower pin of those packages in an application is a NU1605 downgrade as well. redb.Licensing references System.IdentityModel.Tokens.Jwt 8.16.0 (was 8.0.0), so redb.Core.Pro, redb.Postgres.Pro and redb.SQLite.Pro bring the same version without redb.MSSql in the graph.

• UserConfigurationProps.PropsCacheSize is obsolete and no longer merged into EffectiveUserConfiguration: the props cache has one process-wide limit, RedbServiceConfiguration.PropsCacheMaxSize, and no quota per user. The value is still stored with the configuration object; EffectiveUserConfiguration.PropsCacheSize reports the process limit for every user, sys included.

• RedbLazyLoadScopeEndedException: the list item form is ForListItem(listItemId, objectId); the three-argument constructor with its fromListItem flag is gone.

• ObjectStorageProviderBase.CollectAllObjectsRecursively (protected) takes the set of instances already collected, next to the set of ids.

• New public helpers: TransactionCompletion (a provider transaction reports its outcome once; callbacks registered for it run with whether it committed), CachePublication.AfterCommit (runs a publication now or once the context's transaction commits).

Removed

• RedbListItem.SetGlobalObjectLoader, SetGlobalSyncObjectLoader, IsObjectLoaderAvailable, AttachObjectLoader, AttachSyncObjectLoader and HasObjectLoader; IListProvider.LinkedObjectLoader and LinkedObjectSyncLoader; DetachedLazyPropsLoader and ScopeFallbackLazyPropsLoader; the scope factory parameter of GlobalPropsCache.Initialize. These bound items and stubs to one scope, or opened a fresh scope per load to make up for it (see "Lazy loads run on the reader's scope" above).
• MemoryRedbObjectCache constructor parameters getUserIdFunc and getQuotaFunc, its method GetUserStatistics() and the class UserCacheStats: the props cache has no per-user quotas any more (see "Props cache under load" above). The quota lookup ran synchronously on every insert, through a configuration service taken from the scope that initialized redb, and its failures were swallowed.
• Unreachable PostgreSQL SQL in the SQLite and Pro builders. SqliteDialect.Query_HasAncestorTreeSql, Query_HasAncestorNormalSql and Query_HasDescendantSql now refuse with NotSupportedException, like the other search functions SQLite does not have. The Pro SQL builders no longer translate ArrayAny, ArrayEmpty and the ArrayCount… comparisons, which no LINQ parser produces; such a comparison is refused instead of compiling to SQL (on SQLite, to PostgreSQL SQL).

Added

Security

• The default password hasher of a bare redb deployment is bcrypt now, not salted SHA256 (external security report). Every provider's stock user-provider factory used to hard-wire SimplePasswordHasher (SHA256+salt), and IPasswordHasher was not registered in DI at all, so BcryptPasswordHasher sat in the tree unreachable. Now: AddRedb registers IPasswordHasher as bcrypt via TryAdd (your own registration wins), the factories resolve it from DI, and the short user-provider constructors default to bcrypt too. Existing databases are safe: BcryptPasswordHasher.VerifyPassword recognizes both formats, so legacy SHA256+salt hashes keep authenticating and migrate to bcrypt naturally on the next password change. Pinned by PasswordHasherDefaultTests x3 (new hashes carry the $2 bcrypt prefix; a legacy hash still validates and still rejects a wrong password).

Added

• Element-level uniqueness scopes: [RedbUnique(Scope = ...)] on collections (S3 of the subtree-unique plan). Scope = Collection - no duplicate elements inside one object's collection (each element's canonical form is salted with the owning collection identity); Scope = Scheme - element values unique across every object of the scheme, globally probeable via GetByUniqueAsync(p => p.Emails, value). Reference elements canonicalise by TARGET id - Scope = Collection on a collection of references reads as "no duplicate links". The scope lives in _structures._unique_scope (mirrored into the metadata cache) and is delivered by the versioned mechanism (PostgreSQL pvt 0.7.8, MSSQL pvt 0.2.13, SQLite user_version 9); the unique index itself is untouched. A scope change recomputes the structure's keys; Scope on a scalar or nested class is rejected at synchronisation. Pinned by eleven ElemKey scenarios in all six suites, including the change-tracking alignment path (a collection-scoped element added on update is re-keyed with the FINAL collection identity after base-row alignment - without that the salt encoded a discarded candidate id and the duplicate keyed past the stored element).
• _tags: a free-form 450-character marker on _schemes and _structures (reserved for future and custom extensions; indexed on structures, mirrored into the metadata cache, delivered by the same versioned step). [RedbTags("...")] on the Props class or a property writes it at synchronisation; a column WITHOUT the attribute is never touched by sync, so values written directly by applications survive. No semantics imposed by redb.
• [RedbUnique] on a whole nested class, array or dictionary - SUBTREE keys (S1 of the subtree-unique plan). The key is the CONTENT of the subtree: the canonical hash the storage already maintains on the base row, encoded through the same UniqueKeyEncoder formula as scalar keys, so "unique" reads as "no two objects of the scheme hold this exact content". Semantics follow the canonical forms: a dictionary is order-insensitive ({a:1,b:2} IS {b:2,a:1}), a list is ordered ([1,2,3] equals only [1,2,3]), references canonicalise by id (a collection of references reads as "unique SET of references"), an absent or EMPTY collection claims no key. GetByUniqueAsync(p => p.Config, value) accepts the subtree value itself and canonicalises it the way the save did (reference collections are outside the by-value lookup); RecomputeUniqueAsync repairs subtree keys from the stored base-row hashes. In classic SQL the closest shape is an indexed view or a trigger-maintained hash column; here it is one attribute. Pinned by seven Subtree scenarios in all six suites.
• [RedbUnique] on scalars inside nested classes (S2 of the subtree-unique plan). A key field of a nested class - reached from the Props root without crossing a collection - is now a legal unique key: same encoder, same index, same typed RedbUniqueViolationException. GetByUniqueAsync accepts the path both as a lambda (p => p.Identity.Passport) and as a dotted string; RecomputeUniqueAsync takes the same path for explicit backfill. A key inside an ELEMENT of a collection of classes stays rejected at synchronisation: those rows share one structure across every element of every object. The unique index UIX__values__structure_unique now covers keyed rows at ANY position (the old positional filter silently kept nested rows OUT of the index); the new form is delivered to existing databases by the versioned mechanism (PostgreSQL pvt 0.7.7, MSSQL pvt 0.2.12, SQLite user_version 8). Pinned by eight NestedKey scenarios in all six integration suites.
• CancellationToken across the entire async API (discussion #12, item 1). Every async method of the public contracts - storage (IObjectStorageProvider, ~46 methods), queries (IRedbQueryable and friends, grouped/windowed/projected included), schemes, trees, lists, permissions, users, roles, validation, the lazy loader, plus the IRedbService facade - now takes a trailing CancellationToken cancellationToken = default. Source-compatible: existing calls compile unchanged (binary-breaking, as everything in the V4 major). Where the last parameter is params (LockForUpdateAsync, the query/execute family of the contexts) the token rides a paired overload instead - params cannot be followed by anything. The semantics, not just the plumbing: cancellation surfaces as OperationCanceledException and nothing else; a cancelled SaveAsync rolls back completely (rollback and dispose always run on CancellationToken.None - an abort must land even on a cancelled token); the point of no return is the commit - the token is read for the LAST time right before CommitAsync, and the post-commit tail (cache updates, SavedAsync/DeletedAsync interceptors) never consults it again, so "cancelled" can never mean "but actually saved"; DeadlockRetryHelper checks the token before every attempt and cancels its backoff delay; the parallel ChangeTracking diff cancels through ParallelOptions.CancellationToken (one clean OCE instead of an AggregateException pile); the id generator honours the token only at the entry - a refill in flight feeds a shared cache and is never torn mid-way; the synchronous lazy Props getter stays token-free by design (LoadPropsAsync takes one). CancellationTests suite x6: every verb refuses a pre-cancelled token before the first write, an in-flight cancel tears down a server-side sleep (PG pg_sleep, MSSQL WAITFOR), and a cancelled batch save leaves zero rows - or commits whole, never in between.
• PurgeTrashAsync joins the unified cancellation contract. It used to return quietly on a cancelled token (a Cancelled progress report and a soft exit) - the one verb with its own cancellation dialect. Now it throws OperationCanceledException like everything else: the token gates every batch boundary and rides into the purge command itself. The farewell progress report with PurgeStatus.Cancelled still fires before the throw, so a UI knows where the purge stopped. Nothing is lost on cancel: each purge batch commits on its own and the remainder stays queued in the database - the background deletion worker (which now passes its stop token through, so host shutdown actually interrupts a long purge) or any retry picks it up.
• IRedbSaveInterceptor - write-lifecycle interceptors, EF-shaped (discussion #12, items 3-4; owner decision "EF behaviour is what developers know", deletes included by owner decision too). Four hooks with default implementations (subscribe to what you need): SavingAsync fires right after the object graph is collected and BEFORE ids, hashes and the unchanged-set are computed, so an interceptor MAY mutate Props (EF's SavingChanges contract; objects being created still show Id=0 - temporary-key semantics) and an exception CANCELS the whole save; SavedAsync fires after the commit - an exception propagates, but the data is saved; DeletingAsync/DeletedAsync apply the same rules around hard deletes (veto before the SQL, fact after; SoftDelete is not intercepted). Both save hooks run inside the SaveAsync call on the same scope - an audit journal written as redb objects goes through a separate scope (documented on the interface). Register any number via DI; they run in registration order; with no subscribers the pipeline pays nothing. Under ChangeTracking RedbSavedContext.Changes carries the diff the save actually applied (RedbValueChange: Insert/Update/Delete, a model-level PropertyPath - "Title", "Items[1].Price" - plus the old and new row) as a flat projection onto Core types, the tree machinery stays internal; under DeleteInsert it is null. Saving carries NewObjects (references, Id still 0), Saved their final NewObjectIds (works under both strategies) and UnchangedByHash from the F1 shortcut (computed AFTER Saving, so it reflects interceptor edits). This also closes impersonation tracking (item 3): the application sees the objects and the effective user next to whatever real/effective pair it tracks, and writes its own journal. SaveInterceptorTests suite x6 (veto from Saving, propagation from Saved with the data kept, feed per strategy).
• RedbObject: DebuggerDisplay, and ToString() = the canonical JSON (discussion #12, item 2). The debugger shows a short " (id=..., scheme=...)" line with no expanding and no database round-trips; ToString() returns the same contract get_object_json(id) does, through the same serializer - a lazy stub is never woken (base fields + properties:null). A serialization failure neither escapes ToString nor gets swallowed - it rides inside the fallback JSON.
• LoadJsonAsync(id, depth) - the whole object as raw JSON, no CLR props type. A public wrapper over the in-database materializer get_object_json (present on all three providers: a SQL function on PG/MSSQL, a C port inside the native extension on SQLite; the eager load path already uses it). Permission checks as in LoadAsync (DefaultCheckPermissionsOnLoad), not-found per ThrowOnObjectNotFound; the typed props cache is untouched (it is keyed by a CLR type, which does not exist here). Introduced for declarative Route-XML routes: a pure XML module with no assembly reads redb objects (<redbGet id="…"/>), but the method is an ordinary part of IObjectStorageProvider/IRedbService, callable from any code.

Added

• IRedbService.Maintenance - storage maintenance facade (IMaintenanceProvider): AnalyzeAsync refreshes planner statistics with one call on every engine (PostgreSQL ANALYZE, MSSQL sp_updatestats, SQLite PRAGMA analysis_limit; ANALYZE - the limit comes from MaintenanceAnalysisLimit, default 1000), and GetIndexStatsAsync reads index health from the engine's catalogs into one honestly-nullable model (name, table, uniqueness, size, row estimate, usage counters, last use - null where an engine cannot say; SQLite reports no usage at all, MSSQL counters reset on restart, last-use needs PostgreSQL 16+). Explicit calls only - never a side effect of a save. Born out of the 2026-09-10 incident where stale statistics after a bulk seed made a 30ms query run for a second. One implementation in the core; all provider variability lives in three dialect SQL texts normalized to a single column-alias contract.

Fixed

• _hash covers the whole object, and a props-cache hit no longer serves a stale header (cluster review, 2026-09-11). _hash used to cover Props only; the header - name, note, value_*, value_unique, parent, owner, date_begin/complete - was written on every save and never hashed, so a save on another node could change it without moving the hash, and the point load (LoadAsync and its sync twin Load), answering from the cache, handed out a stale header with a valid hash. RedbHash now hashes the header canon together with the Props; only the hash itself, the identity (id, scheme id) and the audit trio (date_create, date_modify, who_change) stay out - they are stamped outside the hash computation and could never be reproduced from a reloaded row. Header dates canonicalise at second precision in UTC. The partial row updates that bypass the save path - a tree move, the trash - reset _hash to NULL so no cached copy outlives them. The cache probe stays the narrow _id/_hash/_id_scheme read and a hit still serves the cached object whole. Consequences: a header-only save no longer takes the ChangeTracking hash shortcut (the values are diffed, not rewritten); value_unique is now hashed - a key change invalidates the cache, which reverses the earlier P5 note below; hashes stored by earlier builds follow the old formula, so such an object misses the cache until its first save under this build (correctness is never at stake: a mismatch is a miss). Pinned by PropsCacheHeaderTests on all three providers, Free and Pro (a second ServiceProvider plays the other node), and by RedbHashHeaderCanonTests.

• Tree loads carry value_unique (found by the same pins). The tree conversions and the reflection row-to-object mapper of the Pro tree provider had not learned the V4 object key: LoadTreeAsync, GetChildrenAsync, LoadPolymorphicTreeAsync and the polymorphic children returned ValueUnique = null on every object. All row-to-object mapping now goes through one RedbObjectRowExtensions (six hand-written copies of the column list removed).

• Scope teardown no longer races an in-flight command (tsum garage report: NpgsqlOperationInProgressException on ReleaseScopes() after an HTTP → SEDA hand-off of RedbListItem; depending on timing the same race also HUNG the disposal outright, which the red pin caught on the un-fixed code). Every provider connection always carried a fail-fast guard against two concurrent commands - but teardown was exempt from it. The shared CommandGate (redb.Core) now gives commands and teardown ONE exclusion on all three providers: DisposeAsync waits for the in-flight command before touching the physical connection, a command entered after teardown began is refused with ObjectDisposedException, and the lazy list-item loader falls back to a detached (fresh-scope) load on that signal - so an item handed across an exchange boundary keeps working instead of dying with the scope. Pinned by ConnectionTeardownTests on all three providers; the reporter's workaround (passing ids instead of live items) is no longer required.

• redb.Export carries the V4 unique-key hash and survives SQLite roundtrips (owner finding). _values._unique was missing from the export entirely - an exported database came back with every [RedbUnique] key silently unenforced until the next scheme sync recomputed them. And on SQLite the uuid-semantic BLOB columns (_users._hash, _schemes._structure_hash, _objects._hash) were read through the driver's GetGuid, which byte-swaps an RFC-ordered BLOB, and written back as TEXT - a roundtrip corrupted every stored hash. All four columns now go through a provider seam (GuidFromDb/GuidToDb): PostgreSQL/MSSQL pass the native Guid, SQLite converts RFC-ordered BLOB(16) both ways (legacy TEXT still read). Genuine binary columns (_value_bytes, _values._ByteArray) never touch the seam. Old backups without the field import cleanly: keys stay NULL and the standing recompute trigger restores them on the next synchronisation. Verified by a SQLite-to-SQLite roundtrip: all four columns byte-identical, JSONL carries canonical guids.

• MSSQL: bulk delete of values by list-item ids no longer scans the whole _values table (E114 finding, 33s cold on a seeded 8.4M-row database). The STRING_SPLIT semi-join form cannot match the FILTERED index IX__values__ListItem_not_null, so the plan degraded to a full clustered scan; the method now sends a chunked parameterized IN list, which seeks the index. The other bulk deletes keep their STRING_SPLIT form on purpose - their indexes are unfiltered and seek fine. Pinned by MsSqlBulkDeletePlanTests over the actual cached plan.

• XML documentation restored for BeginTransactionAsync and the isolation-level ExecuteAtomicAsync overloads (owner finding). The BR-1 wave had inserted the doc comments double-spaced; a blank line splits a /// block, so the compiler dropped the docs of eleven members from the shipped redb.Core.xml / provider XML files (IRedbConnection, IRedbContext, all three provider connections). Also removed two dangling half-blocks in ISqlDialect left over from deleted members.

• Reflective walkers no longer wake RedbListItem.Object (production stand, 2026-09-09). The lazy-loader install walk (and the nested-object cache walk) read every property of every business object - including the lazy Object of list-item fields, whose getter LOADS on read. Materializing anything with dictionary fields therefore fired a synchronous phantom load per item (~150/s on the stand, with not a single explicit .Object in application code). A list item is a leaf now: no reflective walk descends into it.

• NpgsqlDataSource is owned by the container now (factory registration instead of a pre-built instance). Disposing the service provider disposes the data source and closes its connection pool; the old form left every pool open forever, so container restarts (module hot-reload, test runs) stacked orphaned pools of idle sessions until the server-side pruner collected them minutes later.

• FK-column indexes on _values (_ListItem, _Object) - partial, delivered by upgrade (perf finding, 2026-09-10). Both columns carry foreign keys, and without a leading index every DELETE of a referenced object or list item scanned the whole table for the FK check: measured on an ~8.4M-row seed - SQLite 1.5-5.5s, PostgreSQL 5.9s, MSSQL 6.5-7s per check, milliseconds with the indexes. The partial form (WHERE ... IS NOT NULL) keeps them nearly empty - reference fields are a small fraction of rows - so writes barely pay, which is why the full-column ancestors of these indexes (retired for save throughput long ago) stay retired. Fresh databases get them from the base DDL; existing ones through each provider's versioned upgrade (PostgreSQL pvt 0.7.6, MSSQL pvt 0.2.11, SQLite schema version 7), pinned by a delivery test on all six suites.

• SqliteDataSource is disposable and owned by the container now (the SQLite counterpart of the NpgsqlDataSource fix). Microsoft.Data.Sqlite pools are static, keyed by connection string, and a pooled handle keeps the database FILE open - on Windows, locked. Disposing the service provider now clears the pool of its connection string, so a dead container (test host teardown, module hot-reload) releases the file instead of locking it until process exit.

• RedbListItem.Object: the sync getter no longer seizes the process (tsum production freeze, 2026-09-09; reproduced locally: 8 touches of one shared item on a starved thread pool froze the process for 90+ seconds with zero exceptions - even timeout continuations had no thread to run on). Two mechanisms removed: the lock was held ACROSS the load, so every toucher of a shared item (items live in the process-wide list cache) parked behind the first one; and Task.Run needed a SECOND pool thread per touch on top of the one blocked in GetAwaiter().GetResult(). The getter now loads outside any lock and without Task.Run: one blocked thread per touch, concurrent touchers proceed independently, the first published result wins (a racing duplicate load is harmless). Same scenario after the fix: 228ms, all touches parallel. The getter remains a synchronous convenience that blocks a thread - hot paths should prefer IdObject plus an explicit load; the detached-borrow diagnostics point at offenders by stack.

• RedbListItem.Object: the sync getter is thread-pool-free now (the completion of the fix above). The getter used to block over the async load chain, so the parked thread waited for pool-scheduled continuations - on a saturated pool that meant degradation, and on a hard-capped one a total freeze. The whole lazy load now has a synchronous twin down to ADO.NET: sync ExecuteScalar/QueryFirstOrDefault/ExecuteJson on every provider connection, a sync Load on the object storage (same permission check, cache discipline and get_object_json path as the async one on every tier), and a sync linked-object loader wired through the list provider and the process-wide fallback. Loader preference is specificity first, then transport: item-sync, item-async, global-sync, global-async. A/B on the starvation stand (pool hard-capped at 4, 8 touches of one shared item): the blocking-over- async path freezes so completely that even its own watchdog timer never fires; the sync path completes in ~150ms. Custom IRedbConnection/IObjectStorageProvider implementations keep compiling - the new members default to blocking on the async forms.

• ChangeTracking: a failed save no longer poisons the next saves of its scope (Identity backfill report, 2026-09-10). The diff parks its DELETE/INSERT rows in pending channels on the provider instance and the flush cleared them only AFTER each bulk call - so a save that failed mid-flush (a legitimate unique violation, a deadlock retry, a cancellation) left its rows behind, and every following save of the scope re-sent the FAILED object's values inside its own batch. Observable as a serial poisoning: after one legitimate duplicate, unrelated saves die one after another on the failed value's unique hash while their own Props are intact. The channels are reset at the start of every batch save now; the same reset also stops a deadlock retry from doubling the channels. Affected every provider under ChangeTracking (DeleteInsert does not use the channels).

• Props cache: the graph is detached at the hand-OUT, not on Set (tsum production incident). Putting an object into the cache used to swap its lazy loaders to the detached loader immediately - on the very instance the writing request was still working with. Every reference touch of the writer then borrowed a fresh DI scope and a pooled connection, and a parallel tick drained the entire connection pool right after startup. Now Set leaves the writer's scoped loaders alone; a graph is switched to the detached loader once, at the moment the cache actually serves it to another scope (Get, GetWithoutHashValidation, the bulk FilterNeedToLoad), tracked per instance so a hot cache does not re-walk the graph on every hit. The safety invariant is unchanged: nothing served from the cache ever carries another scope's connection.

• Lazy RedbListItem.Object no longer loads through a dead scope, and a disposed context no longer re-opens a connection (production, 2026-09: idle PostgreSQL sessions grew by ~30 a day until a restart; 49 of them had the _types load that ends a materialization as their last statement). Two halves. (1) Every RedbService constructor installed the process-wide RedbListItem object loader over its OWN scoped context; the service is Scoped, so the static pointed at whichever scope was created last - almost always one already disposed - and reading Object ran a load through it. Serializing a list item was enough to read it: the property was visible to System.Text.Json, so an HTTP response or an audit record woke the loader. (2) NpgsqlRedbConnection / SqlRedbConnection / SqliteRedbConnection.GetOpenConnectionAsync saw the null that Dispose leaves behind and opened a NEW physical connection on the dead wrapper; the second Dispose was a no-op, so that connection was never returned, and Npgsql has no finalizer to rescue it - the session sat idle in pg_stat_activity for the life of the process. Now: items carry a loader from the provider that hands them out (IListProvider.LinkedObjectLoader, attached by ListProviderBase on every hand-out and by the Pro materializer), resolving through that scope while it lives and through a fresh scope from the root IServiceScopeFactory once it is gone; the process-wide SetGlobalObjectLoader fallback only ever borrows a fresh scope and no longer captures scoped state; Object is [JsonIgnore] (serialize IdObject, load the object explicitly where the JSON needs it); a context whose scope has ended throws ObjectDisposedException instead of re-opening. Fixed on the way: the loader looked IObjectStorageProvider.LoadAsync up by parameter list, which returned null (NRE at runtime) once that signature grew a CancellationToken; the linked object now loads under the configured permission policy rather than an unconditional skip. Breaking: object disappears from the System.Text.Json output of a list item. Pinned by DisposedScopeGuardTests x6 (every provider, both tiers), PostgresListItemObjectLoaderLeakTests x2 (the production sequence, with pg_stat_activity counting the container's own sessions after its data source is disposed) and RedbListItemSerializationTests.

• SQLite: id-generator self-deadlock inside the caller's transaction (live worker storms: 15-30s "database is locked" waves killing Quartz and every other writer). The id cache is process memory and starts empty, so the first save after startup must fetch a block from the database - a write. When that save ran inside the caller's own BEGIN IMMEDIATE (ExecuteAtomicAsync around SaveAsync - the heartbeat shape), the refill went through a SEPARATE pooled connection and waited for the file's only write lock, held by the very transaction waiting for the refill; only busy_timeout x deadlock retries unwound the pair. Now, inside an active scope transaction, keys are allocated through that same connection (the write lock is already ours - no waiting), bypassing the shared cache: a rollback takes the sequence bump back together with the transaction, and those ids were never visible outside it, so no duplicates on either outcome. PostgreSQL/MSSQL are untouched - their sequences live outside transactions and the trap does not exist there. Pinned by SqliteKeygenInTransactionTests x2: the cold-cache save inside a user transaction was a 33s "database is locked" before the fix and is instant now; ids re-issued after a rollback do not collide.

• A bare (non-generic) RedbObject as a Props field - a loud refusal instead of a crash. The scheme sync classified it as a business class and reflected over the framework's own service fields in two casings (id/Id...): MSSQL died on its CI collation against UNIQUE IX__structures, PG on the reserved-name trigger (23514) - a driver error naming neither the field nor the cure (discussion #12, item 6). The sync now rejects such fields with the hint "declare RedbObject; for raw bytes use byte[]". Pins x6 (scalar + collection).

• NullToDefaultConverter.Write recursed into itself - StackOverflow on the first non-zero primitive serialized with the redb serializer options. A dormant bomb: writes through these Options had only ever met default values, cut off by WhenWritingDefault before the converter. Write rewritten with direct writer.Write*Value calls.

• Pro on PostgreSQL and SQLite never upgraded an existing database: a V4 start over 3.x died with "column _unique does not exist". ProRedbService of both providers silenced EnsurePvtModuleDeployedAsync with a one-liner - on the grounds that Pro generates its queries in C# and needs none of the module's SQL functions. True of the functions, but the same pass carries the schema upgrades (V4 added _structures._unique/_unique_version, _values._unique, _objects._value_unique and their indexes), and those every tier needs. An existing database never received them: the full init runs only on an empty one, and the only catch-up path was switched off - start-up died on the very first scheme read (_unique sits in the Structures_SelectByScheme* column list). MSSQL Pro was not affected - it never skipped. Pins: PostgresProSchemaUpgradeTests, SqliteProUniqueUpgradeTests, MsSqlProSchemaUpgradeTests - the upgrade contract is now checked on all six tier-providers, not only Free (red-before: 4 of 6 red on PG Pro with 42703, SQLite Pro with "no such column: _unique").

• Cross-database poisoning of the structure-tree cache: two services on different databases in one process silently broke each other's saves. StructureTreeCache/SubtreeCache were static dictionaries keyed by scheme_id alone, and scheme ids coincide across databases (same seed): a foreign database warmed the id with ITS tree, the save walked foreign structures, not one property name matched - and the object was written with ZERO value rows, no error anywhere. Cache keys now carry the domain ((domain, schemeId)), derived from the connection string like every other cache. It only ever showed order-dependently (six fixtures in the test process: full gates went 133-468 red depending on class order); after the fix the full gate is 2831/2831.

• MSSQL: base64 in the JSON projection via FOR XML instead of an XML instance - blob reads twice as cheap. CAST(N'' AS XML).value('xs:base64Binary(...)') in four emitter sites cost 112 ms per megabyte against 25 ms for FOR XML PATH(''), BINARY BASE64; the full read of an object with a 1 MB byte[] dropped from 336 to 134 ms server-side. Traps defused by measuring first: without AS [*] the value arrives wrapped in <_ByteArray>...</_ByteArray> and corrupts the JSON, and inside STRING_AGG a subquery is forbidden (Msg 130) - the array and dictionary branches take the value from an OUTER APPLY. Equivalence proven on NULL, the empty array, all three padding classes, all 256 byte values and a megabyte; the bytes suite extended with the same boundaries (78 tests on six fixtures). MSSQL bundle 0.2.10.

• Root value_bytes on Free: Postgres returned bytea hex instead of base64, MSSQL did not emit the field on read at all (what was written came back null). The tail of the docs/BUG_BYTES_FREE_JSON_PROJECTION.md report (§3.2/§3.3): the Б1 claim covered byte[] properties in Props, while the JSON projection walked around the root _objects._value_bytes column. PG 08 - encode(..., base64) without MIME line breaks (bundle 0.7.5); MSSQL 09 - base64 emitted via the XML trick (bundle 0.2.9). The report's manual byte matrix is now the permanent BytesRoundTripTests suite x6 (Props bytes + the scalar BLOB layout + the root bytes reaching the column, pinned against the silent NULL) - red-before: two cells red before the fix, 12/12 after.

• ChangeTracking performance waves F1-F9 (docs/V4/CT_DEEP_REVIEW_PERF.md) - no semantic change, each wave its own commit with a benchmark and a regression run. F1: an object whose recomputed hash matches the persisted one skips the whole value pipeline (id+hash pairs ride the existence check; a 60-object batch with 3 edits - 2-2.5x, resaving untouched up to 9x on SQLite; a batch-neighbour pin). F2: an equal canonical collection base hash cancels the element-by-element walk - and along the way the Ш4 matrix exposed a DEGENERATE collection base-hash canon (a List hashed as Capacity|Count, content never entered) - fixed in its own commit with a red-before pin. F3: deferred sweep of replaced rows in Align instead of a RemoveAll per replacement. F4+F5: ILookups instead of linear scans in tree building and array comparison (B3 -15%, B4 -20%). F6: SQLite bulk UPDATE in chunks via UPDATE FROM (VALUES). F7: the single-object save without the Parallel scaffolding. F9: the P7/Э2 clears only when a key is actually incoming. Full gate 2819/2819.

• "null must be null" - null collection elements read back as nulls on every provider (В-1/В-2/В-3, owner verdict). The Pro materializer lost nulls everywhere: plain arrays shortened, null references collapsed, a ListItem array vanished whole on an empty preloaded set, a dictionary key with a null value was dropped, a null element of a class list read back as an empty object. The Free JSON emitters built an empty object instead of null for class elements. Fixed on one shared discriminator - "a null element is a row without _Guid": five ProPropsMaterializer sites, PG 08 (bundle 0.7.3), MSSQL 09 - array and dictionary (bundle 0.2.5), the SQLite native extension (0.6.4, rebuilt x3). Pins: a null in a primitive array / a null class in a list / a null dictionary value - green x6.

• DTO/MemberInit in all five grouping families; post-Select predicates travel back to SQL; the CT pending channels are real now. The shared selector parser (GroupSelectorMembers) is wired into the plain, tree, array and both window groupers plus the fifth family the tests discovered (standalone WithWindow, where a DTO crashed and unrecognized members silently yielded default). A Where after Select over simple projected props members (nested included) translates back into the source - the filter and the page are server-side; the untranslatable is filtered in memory correctly, and pushdown is refused once the source is already paged (call order). ChangeTracking's diff DELETE/INSERTs ride their pending channels to a single flush point (the DELETE -> UPDATE -> INSERT order preserved).

• GroupBy/Having small fixes (G-4/G-5, CT-5). Having is a copy-on-write builder in both groupers (branching a query used to infect the sibling branch with both predicates); a null constant in HAVING is a loud refusal (it used to become the string "null"); the CT diff lost its positional descendant pairing, and the nested-array alignment limit rose from 10 to 32 passes.

• ChangeTracking on SQLite joined the permanent test coverage - and the in-batch exchange of field unique keys got fixed (CT-1). Investigation showed DeleteInsert in the SqlitePro fixture was a coverage hole, not a deliberate opt-out - under ChangeTracking the set went 436/437 at once (the review's Julian hypothesis disproven). The single red exposed a bulk-layer defect: SQLite executes bulk UPDATE row by row, and swapping [RedbUnique] values between two objects hit the immediate index check; on PG/MSSQL the outcome depended on row order. Fixed x3 providers - the Э2 twin of P7: _values._unique of the rows about to be rewritten is released by one UPDATE before the bulk rewrite, in the same transaction. SqlitePro now runs ChangeTracking permanently: 437/437.

• The dead ChangeTracking twin is gone (CT-3). Next to the living Pro algorithm lay a second, diverging one: the single-object SavePropertiesAsync path with its own Delete/Insert and per-field CT - its entry point had zero callers. The core cluster, Methods.cs whole and two dead SQL methods across ISqlDialect and three dialects removed (-813 lines); the living ProcessNestedObjectsAsync kept. The twin's real risk was never its weight - it was editing the wrong algorithm.

• ChangeTracking: the array base row's hash after element edits is canonical (CT-2 plus the bug hiding under it). The diverging re-computation of the hash from _values rows (string index sort, lost Numeric/ByteArray/null elements) is gone - and the canon pin exposed the real root: UpdateExistingValueFields copied the column by the structure's dbType, which for a collection is the ELEMENT type - the canonical hash in the base row's _Guid was never copied, so every CT edit of array elements left the old hash behind (an eternal pseudo-diff on every following save). New save-invariants suite x6: a re-save is a zero diff (row _id stability under ChangeTracking included), point edits of arrays/dictionaries/nested classes, the hash canon.

• GroupBy.SelectAsync: DTOs supported, everything unrecognized is loud (G-1/G-2/G-3, owner decisions). A DTO with a member initializer (MemberInit) materializes on par with an anonymous type - every row used to come back null silently. A selector member that uses the group but is neither g.Key nor a direct Agg.* call - NotSupportedException naming the member (used to be a silent null); a member with no group reference is a client-side value computed once. A computed grouping key is a loud refusal (used to be a silently empty GROUP BY). Array/Tree/window groupers gained a fail-closed guard on non-anonymous selectors.

• Select: Take/Skip called after in-memory operations now cut the filtered rows (S-4, owner decision 2026-09-04). A Take issued after Where-after-Select went into SQL before the filter - the server returned whatever page came first and rows were silently lost (Skip skewed the pages). Such Take/Skip now apply in memory after the filter/sort in call order; Take/Skip before any in-memory operation keep the server-side LIMIT. The canonical Where-before-Select order stays fully server-side as it was.

• The SaveAsync operational guard, EF-style (CT-4, owner decision 2026-09-04). A second save entering the same scope before the first completes (interleaved async operations the connection's command guard cannot see) gets a loud InvalidOperationException in the EF-DbContext style - instead of silently scrambling ChangeTracking's pending state.

• Select projections: the first e2e suite and a fix pack (review 2026-09-03). 16 scenarios x6 fixtures (red-before 24/96): fixed the OrderBy-after-Select crasher on a null key (Comparer