Skip to content

chore(deps): update all non-major dependencies - #156

Open
renovate[bot] wants to merge 2 commits into
mainfrom
renovate/all-minor-patch
Open

chore(deps): update all non-major dependencies#156
renovate[bot] wants to merge 2 commits into
mainfrom
renovate/all-minor-patch

Conversation

@renovate

@renovate renovate Bot commented Aug 31, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Change Age Confidence Type Update Pending
@harperfast/skills (source) 1.12.2 → 1.12.4 age confidence dependencies patch 1.12.5
harper (source) 5.2.4 → 5.2.7 age confidence devDependencies patch
hono (source) 4.13.3 → 4.13.5 age confidence devDependencies patch
node (source) 24.19.0 → 24.20.0 age confidence minor
oxlint (source) 1.79.0 → 1.80.0 age confidence devDependencies minor
puppeteer (source) 25.8.0 → 25.9.0 age confidence optionalDependencies minor
zod (source) 4.4.3 → 4.5.2 age confidence dependencies minor 4.5.4 (+1)

Release Notes

HarperFast/skills (@​harperfast/skills)

v1.12.4

Compare Source

Documentation

v1.12.3

Compare Source

Documentation
harperfast/harper (harper)

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

v5.2.6

Compare Source

Transactions and data integrity

  • An explicit transaction() was not atomic when the context's transaction slot already held a released placeholder (HarperFast#2325, cherry-picked as HarperFast#2327). In that state — and on a context that never held a transaction at all, such as an instance load — txnForContext installs an ImmediateTransaction, which reports itself open but whose save() is the commit. Both join sites gated on the open flag alone, so transaction(ctx, cb) ran the callback and returned without ever reaching its own commit: every write self-committed as it happened, a throw partway through left the earlier writes durable, the error path's abort() never ran, and the handler still returned success. Both join sites now gate on whether the transaction stages its writes for a later commit, so an explicit transaction() on a released slot is atomic exactly as it is on a fresh one. Reachable in 5.2.1 through 5.2.5.

Restarts and shutdown

  • A worker respawn could resurrect the thread pool mid-shutdown (HarperFast#2316). Terminal process shutdown now latches worker creation and every replacement path, so a late worker exit or an overlapping rolling restart can no longer bring the pool back while the process is tearing down. The restart path sets that latch as its first act rather than waiting for shutdownWorkersNow(), closing the window where a debounced component reload could pre-start an HTTP replacement inside a process that is already exiting.
  • Container restarts gain a bounded post-compaction exit watchdog (HarperFast#2316). Every way the watchdog's shell could give up was a silent success — an unreadable procfs, a base image without sleep — so a successful spawn was not evidence it would ever fire. It now emits a readiness token once both facilities are proven, and arming reports failure unless that token arrives, so the "restart teardown is unbounded" warning reaches operators in exactly the environments that need it.
  • The published image runs tini -g as PID 1 (HarperFast#2316). This gives the container a reaper and makes a reliable SIGKILL fallback possible, while preserving compatibility with volumes written by earlier PID-1 images. Worth knowing on upgrade: group signal forwarding changes which signals component subprocesses receive on docker stop; the user-visible consequences are recorded in DESIGN.md.
  • Shutdown listeners preserve requested failure exit codes and still terminate the process when PID-file cleanup fails, rather than exiting 0 or hanging (HarperFast#2316).

Also in this release

  • CI: the dispatched test workflows are pinned to a read-only token (HarperFast#2318).

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

v5.2.5

Compare Source

Transactions and data integrity

  • A write issued after its transaction scope had completed could be silently dropped (#​2291, cherry-picked as #​2307). When a table call found no live transaction on its context — including the placeholder a completed scope leaves behind — it built an ImmediateTransaction whose native handle the commit path then discarded, staged writes and all. There was no error and no log line: the caller's await resolved normally over a record that was never written. On 5.2.4 this failed Central Manager's POST /Cluster on every request. 5.1 and 5.2.0 were unaffected — the loss is latent in the commit path but only became reachable once a completed scope started leaving a released-transaction placeholder in the slot.
  • Writes after an explicit mid-scope commit are atomic with the scope that owns them again (#​2239). A handler that commits its own transaction mid-scope — the documented await getContext().transaction.commit() — had each subsequent write in that scope serviced and committed on its own, so a handler that failed halfway left the earlier half durable and unrollbackable. That is the mechanism behind a failed cluster delete leaving a cluster marked TERMINATED with its instances still RUNNING. A successful commit that is not the scope's final one now rotates the owning transaction to a fresh open generation. LMDB has always behaved this way; only the RocksDB path diverged, so this closes a property the 4.7 → 5.x upgrade quietly dropped rather than adding a new one.

Operations and observability

  • get_status now waits for every live worker thread (#​1952). Collection was sized from a logical worker count and could return before all physical threads had replied. During a rolling restart an old and a replacement thread can share a logical worker index, so one response overwrote the other and could hide an error. The collector now snapshots the eligible physical thread IDs and completes only once each has replied, keeping overlapping generations distinct internally. The response payload is unchanged — duplicate generations still collapse to the existing name@worker-N label, retaining the worst status. Worth knowing on upgrade: a routine redeploy can now surface a real transient loading or error state that the previous overwrite accidentally masked.

Vector search

  • HNSW index quality scales with graph size (#​2181). A fixed construction candidate list eventually stops creating enough useful edges, so recall degrades as a graph grows. efConstruction now auto-scales from a base of 100 as min(1024, 100 × sqrt(nodes / 250K)), and the search-ef ceiling resumes scaling above one million nodes, up to 2048. Graphs below 250K nodes keep the previous default, and nodes inserted before a scale threshold keep their existing edges — the ramp applies to new inserts and to a reindex. An explicit efConstruction, efConstructionSearch, or per-query ef remains an authoritative cost ceiling, so a pinned index can return fewer rows than limit unless the query supplies a larger ef.

Also in this release

  • CI: the v5.2 branch now pins the same ai-review-prompts revision as main, restoring AI review coverage for PRs that target the release branch (#​2308).

Full Changelog: HarperFast/harper@v5.2.4...v5.2.5

honojs/hono (hono)

v4.13.5

Compare Source

v4.13.4

Compare Source

nodejs/node (node)

v24.20.0: 2026-08-26, Version 24.20.0 'Krypton' (LTS), @​aduh95

Compare Source

Notable Changes
Commits

✂ Note

PR body was truncated to here.

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.

This was referenced Aug 31, 2026
Merged
Merged
Merged
dawsontoth
dawsontoth previously requested changes Aug 31, 2026
View reviewed changes

@dawsontoth dawsontoth left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Requesting changes — the lockfile is pruned, the bumps themselves are fine

npm ci fails on this branch. This is the fourth occurrence of the harper lockfile-pruning problem (#141, HarperFast/vite#37, #154, now this one), and the failure signature is the giveaway: commitlint is green while Format, Lint, Build and Test are all red — commitlint is the only job in this repo that doesn't run npm ci.

What happened

Renovate re-resolved harper 5.2.4 → 5.2.6 and npm dropped harper's optional alasql → react-native subtree from the lockfile:

base 67e9ef25 head df67aac0
packages keys 1648 1403
react-native* entries 28 0

Reproduced locally (Node 24.17.0):

$ npm ci --ignore-scripts
npm error Missing: react-native-fs@2.20.0 from lock file
npm error Missing: react-native@0.84.1 from lock file
npm error Missing: @jest/create-cache-key-function@29.7.0 from lock file
... 246 total `npm error Missing:` entries
exit 1

The bumps are good — please don't drop versions trying to fix this

I healed the lockfile locally and everything passes, so the version movement is not the problem:

$ npm install          # one full reify
keys: 1403 → 1649, react-native*: 0 → 28, harper: 5.2.6
$ rm -rf node_modules && npm ci     # exit 0
$ npm run build   → exit 0
$ npm run lint    → exit 0
$ npm run format  → exit 0 (dprint check)
$ npm test        → 53 files / 345 tests passed

Structural lockfile audit of base vs. the healed tree: 32 version changes, 0 major crossings, 0 removed, 1 added. Top-level moves are harper 5.2.4 → 5.2.6, @harperfast/skills 1.12.2 → 1.12.4, oxlint 1.79.0 → 1.80.0 (+ platform binaries), puppeteer/puppeteer-core 25.8.0 → 25.9.0, hono 4.13.3 → 4.13.5, terser 5.50.0 → 5.51.2, and browserslist data. All clean.

The fix

One full npm install on top of this branch, committed. Note the qualifiers, both learned the hard way:

  • npm install --package-lock-only does not heal it — it has to be a real reify.
  • A Renovate rebase does not self-heal it either; #154 came back with the identical symptom after one.

This should stop being a manual step

Three of the four occurrences have been hand-fixed. Fourth time round, the equilibrium is wrong — a Renovate postUpgradeTasks running a single npm install after the bump would close it permanently. Happy to open that as its own PR against renovate.json if nobody's already on it.

Worth noting the sibling PRs took the same harper bump and were unaffected: #155 (keys 1648, rn 28) and HarperFast/vite#42 (keys 1460, rn 19) both npm ci clean. So the trigger is resolution-path-dependent, not a property of harper@5.2.6 — the react-native key count remains the cheap per-repo check.

@dawsontoth dawsontoth mentioned this pull request Aug 31, 2026
Merged
1 task
@renovate
renovate Bot force-pushed the renovate/all-minor-patch branch 2 times, most recently from be3c52e to 41e6176 Compare August 31, 2026 18:43
@renovate
renovate Bot force-pushed the renovate/all-minor-patch branch from 41e6176 to fe9f690 Compare September 1, 2026 00:39
@dawsontoth

dawsontoth commented Sep 1, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Re-checked at fe9f690 — the rebase did not heal it (5th occurrence)

Renovate force-pushed over the head I reviewed on 08-31. The lockfile blocker recurred identically. My CHANGES_REQUESTED stands; this is a short confirmation, not a re-litigation of the previous write-up.

Node 24.19.0:

base main PR fe9f690 after one npm install
lockfile keys 1649 1403 1649
react-native* entries 28 0 28
harper 5.2.4 5.2.7 5.2.7 
$ npm ci --ignore-scripts
npm error `npm ci` can only install packages when your package.json and package-lock.json ... are in sync
... 246 total `npm error Missing:` entries
exit 1

246 missing entries — the same count as the last round. This is the same signature as #141 / #154: commitlint green while Build / Format / Lint / Test are all red.

The bumps themselves are still good

One full npm install, then a clean-slate verify — everything passes:

$ rm -rf node_modules && npm ci   → exit 0
$ npm run build                   → exit 0   (DTS Build success in 1197ms)
$ npm run lint                    → exit 0   (oxlint)
$ npm run format                  → exit 0   (dprint check)
$ npm test                        → 53 files / 345 tests passed

Structural lockfile audit, base vs. healed tree: 34 changed, 1 added, 0 removed, 0 major crossings. Top-level movement is harper 5.2.4→5.2.7, @harperfast/skills 1.12.2→1.12.4, oxlint 1.79.0→1.80.0 (+ platform binaries), puppeteer/puppeteer-core 25.8.0→25.9.0, hono 4.13.3→4.13.5, terser 5.50.0→5.51.2, zod 4.4.3→4.5.2, and browserslist data. All clean. package.json is unchanged — this is a lockfile-only PR.

No @ai-sdk/* or @openai/agents-extensions movement in this batch, so the spec-version gate is not in play here. No ink-stepper change either.

The fix, unchanged

One full npm install on top of this branch, committed. Both qualifiers still apply, and this round is fresh evidence for the second one:

Fifth time — this should stop being a manual step

Four of the five occurrences have now been hand-fixed, and the fifth is this comment. A Renovate postUpgradeTasks running a single npm install after the bump would close it permanently. I'm happy to open that against renovate.json as its own PR if nobody's already on it — say the word and I will.

🤖 Verified locally, Node 24.19.0

@dawsontoth @claude
chore(deps): heal lockfile with a full npm install
c166d2f 
Renovate generated this branch's lockfile without a full reify, so the
`harper` bump pruned the optional `harper > alasql > react-native`
subtree: 1403 keys / 0 `react-native` entries against 1649 / 28 on main.
`npm ci` then failed EUSAGE with 246 `Missing:` entries, taking Build,
Format, Lint and Test red while commitlint stayed green.

One full `npm install` restores it. The result is purely additive
against the Renovate lockfile — 246 added entries (exactly the 246
`npm ci` reported missing), 0 version changes, 0 removals — so none of
the proposed bumps move.

Verified on a clean slate (Node 24.19.0): npm ci, build, lint, dprint
check, and 53 files / 345 tests all pass.

This recurs on every `harper` bump and a Renovate rebase does not heal
it (cf. #141, #154), which is why this is a manual commit on top.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@dawsontoth

dawsontoth commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

Healed and pushed — CI is green at c166d2f

I took the branch over rather than asking Renovate for another rebase, since a rebase demonstrably doesn't heal this (that's what produced fe9f690 in the first place). Because there's now a non-Renovate commit on the branch, Renovate will leave it alone unless someone ticks its rebase checkbox — please don't, it would re-prune the lockfile.

c166d2f touches package-lock.json and nothing else.

The heal is purely additive — no bump moved

Diffing the Renovate lockfile against the healed one:
version changes 0
removals 0
additions 246 — exactly the 246 entries npm ci reported missing

So every version in this PR is still the version Renovate proposed. The commit only restores the pruned harper > alasql > react-native subtree: 1403 → 1649 keys, 0 → 28 react-native entries, matching main.

CI

check before after
Build ❌ ✅ 52s
Format ❌ ✅ 57s
Lint ❌ ✅ 1m1s
Test (ubuntu-latest, Node 24) ❌ ✅ 1m2s
commitlint ✅ ✅ 16s

Also verified locally on a clean slate before pushing (rm -rf node_modules && npm ci → exit 0, then build / lint / dprint check / 53 files / 345 tests). Local run was Node 24.19.0; .nvmrc pins 24.20.0 and CI ran that, so the table above is the authoritative signal.

I'm clearing my CHANGES_REQUESTED since the blocker I raised is fixed — but I'm not self-approving, because I wrote the fix. It needs a second pair of eyes on package-lock.json; the useful thing to check is the additive-only claim above, which git show c166d2f -- package-lock.json will confirm.

Still worth doing separately

Fifth occurrence. A Renovate postUpgradeTasks running one npm install after the bump would close this permanently — happy to open that against renovate.json if nobody's on it.

🤖 Healed and verified locally, Node 24.19.0

@dawsontoth
dawsontoth dismissed their stale review September 1, 2026 15:55

Blocker fixed in c166d2f — lockfile healed, all five checks green. Not self-approving since I authored the fix; needs a second reviewer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@dawsontoth dawsontoth dawsontoth left review comments

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@dawsontoth