chore(deps): update all non-major dependencies

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
@types/react-dom (source)	19.2.5 → 19.2.7
argue-cli	3.1.0 → 3.2.0
harper (source)	5.2.6 → 5.2.9

---

Release Notes

TrigenSoftware/Argue (argue-cli)

v3.2.0

Compare Source

Features

• add [String] and [Number] option types to collect repeated options (#​396) (23d6fb9)

harperfast/harper (harper)

v5.2.9

Compare Source

Write stalls

The RocksDB WriteBufferManager no longer stalls writes by default (#​2490). The process-wide WriteBufferManager is on by default at 1/3 of the block cache, and it was configured as a hard cap: when the budget filled, RocksDB parked every writer across every database in WriteBufferManagerStallWrites(), and nothing guaranteed the flush that would release them. ShouldFlush() only fires when mutable memory alone reaches half the budget, so a budget held by memory that is not mutable — the shape you get when it is spread across many column families — never dropped, and the only way out was a process restart.

The budget is now a soft cap: RocksDB schedules flushes more aggressively instead of blocking writers. Explicitly configured writeBufferManagerAllowStall values still win in both directions.

The trade is memory. With stalling off, each column family keeps its full derived conflict-check history (maxWriteBufferNumber * writeBufferSize) rather than having it derived to zero, so expect a higher memory floor on instances with many column families. rocksdb-js#821 is the other half of the fix.

Query planning

Table sizing for query planning is now O(1) (#​2478). estimatedEntryCount() iterated the entire key space natively, on the main thread, once per store per 10-second memo window — and the memo never took effect, because the window was sampled before the call and had already expired by the time it returned. On a 28.6M-row table that is roughly 11 seconds per call, and the planner calls it once per additional condition, so a 10-condition operation measured around 100 seconds of main-thread stall with the Operations API unresponsive throughout.

It now reads rocksdb.estimate-num-keys, which is O(1) and returned an identical count on the affected table. The estimate skews high on overwrite- and delete-heavy data until compaction; every consumer is a relative-ordering or explicitly-estimated path, so that trade is deliberate. Two arithmetic sites that a zero estimate would have broken — the AND-group divisor, which yielded Infinity and silently disabled the adaptive filter/index switch, and the ne null subtraction, which could go negative — are guarded.

Replication configuration

The blob-gap escalation bounds are registered — replication.blobGapEscalationCycles and replication.blobGapEscalationMs now exist in CONFIG_PARAMS, the config validator, and the root config schema. env.get resolves only registered names, so without this the keys would sit in harper-config.yaml doing nothing while the compiled-in defaults stayed in force. The consumer is the Harper Pro escalation budget described in that release's notes; see the harper-pro v5.2.9 notes for the operator-facing behavior.

Also in this release

CI workflow sync for the cancellation migration (#​2387), and test-only cleanups alongside the changes above.

v5.2.8

Compare Source

Storage engine

• A commit parked on a write intent that was never released could wedge the worker thread (HarperFast#2466). rocksdb-js 2.8.0 bounds the coordinated-retry park with ROCKSDB_JS_PARK_TIMEOUT_MS (HarperFast/rocksdb-js#744), so a commit waiting on an intent that never gets released now wakes and consumes a retry attempt instead of never settling. Previously that wait had no upper bound, and the thread holding it stayed parked.

  The root msgpackr pin moves to 2.0.6 alongside it. check-shrinkwrap-pins.mjs requires the root pin to equal rocksdb-js's own so that one module instance — and therefore one structure and extension registry — is shared, and rocksdb-js 2.8.0 depends on msgpackr 2.0.6. Over 2.0.5 that is a single decode-hardening change: array and map lengths that exceed the remaining source data are now rejected rather than trusted. The lockfile loses the nested msgpackr copy under rocksdb-js accordingly. This is the version main already runs.

Replication & subscriptions

• RocksDB subscription listeners dropped every source-fill event as out-of-order, and catch-up replayed patch entries with no value (HarperFast#2445, backport of #​2409). A source fill writes with the transaction's commit timestamp, but the RocksDB transaction-log reader overwrote the decoded record version with the log key. The subscription listener's staleness check then compared a record version against a log position and discarded the event. The same reader left auditRecord.localTime unset, so collection startTime replay called getValue() with no reconstruction time and delivered patch entries with value: undefined.

  The entry's own version is now exposed as AuditRecord.recordVersion, surviving the log-key override, and the staleness check compares record versions; raw same-thread aftercommit entries are stamped with the same two clocks the decoded path reports. version deliberately stays the log key — replication resume relies on version === log key — so cursor advancement, transaction grouping, and resume semantics are unchanged. Only the RocksDB engine was affected; LMDB was already correct.

MCP

• Every table Resource manufactured a create_* MCP tool, whether or not it had a real create verb (HarperFast#2405, fixes #​1945). detectVerbs()'s create check was typeof p.post === 'function' || typeof p.update === 'function', but Resource.prototype defines a base post() (resources/Resource.ts), so the first clause was true for every Resource subclass regardless of what it overrode — making the check unconditionally true and the update clause moot. Agents were offered create tools that had nothing behind them.

  The check now reuses toolRegistry.ts's hasClassLevelVerbs(), which identity-compares against Resource.prototype and so counts only a real override, or the implicit update() override that Table.ts's write path relies on. An instance-level create() override counts directly as well: Resource.post's loadAsInstance === false branch dispatches straight to it, bypassing both post and update, and a resource built that way would otherwise have silently lost its create_ tool.

Also in this release

• Test coverage for the two fixes above: a transaction-broadcast grouping test for the subscription path, a catch-up regression test pinning the client-observable "a replayed patch carries a full value" contract on both storage engines (HarperFast#2444), and an MCP fixture corrected to match Table.ts's actual shape (it defines create() alongside update()).

Full Changelog: HarperFast/harper@v5.2.7...v5.2.8

v5.2.7

Compare Source

Data integrity

• Resolved @computed and @relationship values were written into durable records, and the affected rows then became unreadable and undeletable (HarperFast#2368). A record resolved from a cache source carries the record prototype, whose response projection (toJSON) surfaces scalar @computed values — and @enumerable relationships since 5.1.0. msgpackr consults an instance's toJSON when encoding it, so the durable encode ran the response projection and wrote the resolved values as stored fields. Materializing such a record then assigns the stored value back through the resolver accessor, with two distinct outcomes:

  • a computed attribute has no setter, so every read, query, invalidate and delete on that record threw attribute.set is not a function — reachable in 5.2.0 through 5.2.6;
  • a relationship setter dereferences the stale value, so a dangling foreign key crashed the same way (since 5.1.0), and a scalar collision silently destroyed the foreign key.

  The write side now enforces the invariant at the layers that own it. recordUpdater projects the record — and the audit entry's own record, gated so message and publish payloads stay verbatim — to its stored fields before anything durable is written, dropping any name a resolver owns whether it arrived through the response projection, from a source, or in a peer payload. A source that returns a related object instead of its foreign key still has the key derived through the writable resolver's setter before the name is dropped. structon is pinned to 1.1.0, which writes own properties only, matching msgpackr's object writers and closing the prototype-walk route for every struct encode.

  The read side makes the records that affected releases already wrote recoverable: the four paths that promote a plain decode to a record instance now skip resolver-owned names instead of assigning them through the accessors, and the accessor itself drops such an assignment (warning once per table) rather than calling an absent setter. A schema reload clears attribute.set alongside attribute.resolve, so changing an attribute from @relationship to @computed cannot retain a stale setter. If you are on 5.1.x–5.2.6 and have hit attribute.set is not a function, upgrading is what makes those rows readable and deletable again.

• A prototype-chain walk could copy inherited properties into a durable record (HarperFast#2368). assignStoredFields used for..in, so an inherited enumerable — including anything on a polluted Object.prototype — could reach a materialized and then durable record on exactly the paths that its own Object.assign fallback and storedFieldsOnly already restrict to own properties. It now reads own keys only.

Schemas

• @computed(from:) expressions failed to compile in an inline-loaded schema (HarperFast#2360, landed via #​2368). vm.Script requires a string filename and inline schemas were loaded with a null one, so any computed expression in such a schema threw. Reported and fixed by @​kylebernhardy.

Behavior changes worth knowing on upgrade

• Assigning to a @computed attribute now throws a client error naming the attribute, instead of a TypeError from the missing setter.
• Harper does not set msgpackr 2.1.0's useToJSON opt-out. That is deliberate: an encoder-wide opt-out would also silence the legitimate toJSON of nested values, so the projection is enforced at the layers that write durable records rather than in the encoder.

Also in this release

• CI: the bot caller workflows are synced with main, and the always-on review arm no longer cancels ready_for_review runs (HarperFast#2331, HarperFast#2358). resources/DESIGN.md records the durable-vs-response projection convention behind the fix above.

Full Changelog: HarperFast/harper@v5.2.6...v5.2.7

---

Configuration

📅 Schedule: (in timezone America/New_York)

• Branch creation
  • "before 9am on Monday"
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.