Dependency Guard

This PR changes dependency-related files. Maintainers should confirm these changes are intentional.

Changed files:

• extensions/memory-lancedb/npm-shrinkwrap.json
• extensions/memory-lancedb/package.json
• pnpm-lock.yaml

Maintainer follow-up:

• Review whether the dependency changes are intentional.
• Inspect resolved package deltas when lockfile, shrinkwrap, or workspace dependency policy changes are present.
• Treat package-lock.json and npm-shrinkwrap.json diffs as security-review surfaces.
• Run pnpm deps:changes:report -- --base-ref origin/main --markdown /tmp/dependency-changes.md --json /tmp/dependency-changes.json locally for detailed release-style evidence.

Dependency graph changes are blocked

OpenClaw does not accept dependency graph changes through PRs unless a repository admin or security explicitly authorizes the current head SHA. Dependency updates are generated internally by maintainers so external PRs cannot change the resolved graph.

Detected dependency graph changes:

• extensions/memory-lancedb/npm-shrinkwrap.json changed.
• pnpm-lock.yaml changed.
• extensions/memory-lancedb/package.json changed dependencies.

Auto-scrub was not attempted because this PR changes package manifest dependency graph fields:

• extensions/memory-lancedb/package.json changed dependencies.

Dependency graph changes must be reviewed by security or handled by maintainers internally. Please remove lockfile changes manually if they are not needed.

To remove lockfile changes, restore them from the target branch:

git fetch origin
git checkout 'origin/main' -- 'extensions/memory-lancedb/npm-shrinkwrap.json' 'pnpm-lock.yaml'
git commit -m 'chore: remove dependency lockfile change'
git push

If this PR intentionally needs a dependency graph change, ask a repository admin or member of @openclaw/openclaw-secops to comment:

/allow-dependencies-change

The action will approve the current head SHA (f4fea32b3def76e19b3e3ab5a29ab3524521e2d0) when it reruns. A later push requires a fresh approval.

This dependency graph change is intentional for #90295: @lancedb/[email protected] declares apache-arrow peer range >=15.0.0 <=18.1.0, while the current memory-lancedb package pinned [email protected] and npm 11 rejects the install. This PR pins apache-arrow to 18.1.0 and regenerates the plugin shrinkwrap with the repo generator.\n\nLocal proof run on this head:\n- npm view @lancedb/[email protected] peerDependencies --json -> { "apache-arrow": ">=15.0.0 <=18.1.0" }\n- pnpm install --frozen-lockfile -> already up to date\n- node scripts/generate-npm-shrinkwrap.mjs --check --package-dir extensions/memory-lancedb -> current\n- npm install --prefix --ignore-scripts ./extensions/memory-lancedb --package-lock-only -> up to date\n- pnpm test extensions/memory-lancedb --reporter=dot -> 134 passed\n- node scripts/run-vitest.mjs src/plugins/contracts/package-manifest.contract.test.ts src/plugins/contracts/extension-runtime-dependencies.contract.test.ts --reporter=dot -> 430 passed\n\nDependency Guard requires a repo admin/security approval for this head SHA if maintainers want this dependency repair via external PR.

Codex review: needs maintainer review before merge. Reviewed June 30, 2026, 10:45 AM ET / 14:45 UTC.

Summary
The PR changes memory-lancedb's apache-arrow dependency from 21.1.0 to 18.1.0 and regenerates the plugin shrinkwrap plus root pnpm lockfile.

PR surface: Source +14, Config 0, Other +2. Total +16 across 3 files.

Reproducibility: yes. Source, shrinkwrap, root lockfile, latest published package metadata, and live LanceDB npm metadata show Arrow 21.1.0 outside LanceDB 0.30.0's accepted peer range; I did not run an install in this read-only review.

Review metrics: 1 noteworthy metric.

• Dependency graph surfaces: 1 manifest dependency changed; 2 graph files regenerated. The manifest, plugin shrinkwrap, and root lockfile must be reviewed together because dropping any one leaves install metadata inconsistent.

Stored data model
Persistent data-model change detected: unknown-data-model-change: extensions/memory-lancedb/npm-shrinkwrap.json, vector/embedding metadata: extensions/memory-lancedb/npm-shrinkwrap.json. Confirm migration or upgrade compatibility proof before merge.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #90295
Summary: This PR is the open fix candidate for the canonical memory-lancedb Arrow/LanceDB peer conflict issue; the later short report was already closed as a duplicate.

Members:

• canonical: memory-lancedb 2026.6.1 fails to install: apache-arrow 21.1.0 conflicts with @lancedb/lancedb 0.30.0 peer range #90295 - The PR body uses closing syntax for this open issue, and the issue describes the same npm ERESOLVE conflict with full environment and failure logs.
• duplicate: Issue on memory-lancedb #90877 - The closed issue reports the same memory-lancedb Arrow 21.1.0 and LanceDB 0.30.0 incompatibility and its close comment points back to the canonical issue plus this PR.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🦐 gold shrimp
Proof: 🦞 diamond lobster
Patch quality: 🦐 gold shrimp
Result: needs maintainer review before merge.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• Rebase against current main and regenerate the package graph files if they drift.
• [P2] Have secops/admin inspect the resolved graph and authorize the exact refreshed head SHA, or apply the same fix from a trusted maintainer branch.

Risk before merge

• [P1] The PR intentionally changes a package manifest, plugin shrinkwrap, and root lockfile from an external branch, so secops/admin review must authorize the exact resolved graph before merge.
• [P1] GitHub reports the PR as dirty/conflicting; any rebase or regenerated graph will produce a new head SHA that needs fresh dependency-graph authorization.
• [P1] Downgrading Arrow to the LanceDB-supported peer range changes transitive shrinkwrap packages, so install proof does not replace supply-chain review of the resolved graph.

Maintainer options:

1. Refresh and authorize the exact graph (recommended)
   Rebase against current main, regenerate graph files if needed, inspect the dependency delta, then have secops/admin authorize the exact refreshed head SHA before merge.
2. Apply the repair internally
   Maintainers can reproduce the same manifest, shrinkwrap, and lockfile change from a trusted branch and use that as the landing path.
3. Pause the external graph change
   If maintainers do not want external dependency graph changes, keep this PR paused or close it only after an internal replacement is opened or merged.

Next step before merge

• [P2] Manual review is needed because the remaining work is trusted dependency-graph authorization plus conflict refresh, not a safe autonomous code repair on this external branch.

Security
Needs attention: The diff is a legitimate dependency repair, but the external dependency graph and shrinkwrap changes need trusted resolved-graph review before merge.

Author-side follow-up: I do not think there is a code/test change to make here without undoing the fix. The dependency graph change is intentional for #90295, and ClawSweeper already marked proof and patch quality sufficient.

Remaining blocker appears to be repository policy: dependency graph changes from an external PR need repo admin or secops approval for the current head SHA, or maintainers can choose to apply the same graph change internally from a trusted branch.

I am leaving the branch unchanged pending that maintainer/security decision.

Confirming this is an intentional dependency-graph change for #90295, and the proof gate is now green.

Check status

• Real behavior proof ✅ — the PR body now carries the structured after-fix proof: the live npm peer-range query plus a real npm 11 before/after reproduction against the published @lancedb/[email protected] ([email protected] → ERESOLVE, exit 1; [email protected] → resolves, exit 0).
• dependency-guard ⛔ — the only remaining blocker, which by policy needs an admin / @openclaw/openclaw-secops authorization of the current head SHA.

Exact delta (small and mechanical)

The three files must change together: dropping the lockfile/shrinkwrap regeneration leaves apache-arrow mismatched against the manifest, and a frozen install then fails with ERR_PNPM_OUTDATED_LOCKFILE. So the lockfile changes are required, not incidental.

To inspect the full resolved-graph delta:

pnpm deps:changes:report -- --base-ref origin/main --markdown /tmp/dependency-changes.md --json /tmp/dependency-changes.json

Could an admin or @openclaw/openclaw-secops member review the delta and, if acceptable, comment /allow-dependencies-change to authorize head f4fea32? If you'd rather keep dependency-graph changes internal, I'm happy to have it regenerated from a maintainer branch instead.

@steipete

Adding live user-impact context from #90295.

This is still affecting real installs after the 2026.6.5 update. The latest published @openclaw/[email protected] still declares:

• @lancedb/[email protected]
• [email protected]

But @lancedb/[email protected] still peers apache-arrow >=15.0.0 <=18.1.0, so normal npm resolution is still broken.

I have now had to keep memory-lancedb pinned back at 2026.5.28 across multiple OpenClaw updates to keep LanceDB memory working. That workaround is functional, but this is a core part of the memory stack and it is pretty painful to rediscover/reapply during updates.

It also looks like this PR is not really waiting on the author anymore. The author has already confirmed the dependency graph change is intentional and that the remaining blocker is maintainer/security authorization for the dependency change, or for maintainers to apply the same fix from an internal branch.

Could a maintainer either authorize this exact dependency fix or apply the equivalent trusted-branch fix and publish a repaired memory-lancedb package? The current published package is still broken for standard npm installs.

This PR only realigns memory-lancedb's apache-arrow to 18.1.0 to match the version @lancedb/[email protected] actually resolves against (21.x drifts the peer and breaks the native Arrow FFI at runtime). The lockfile/shrinkwrap deltas are the mechanical result of that single version pin.

The dependency-guard check is the policy gate for any dependency-file change, so this needs a maintainer/secops /allow-dependencies-change to proceed. Could a maintainer apply it? Happy to rebase the lockfiles onto current main if the tree has drifted since.

Thanks @sahibzada-allahyar. Your diagnosis and dependency-alignment patch were correct.

Closing as superseded by #99118 and commit 968aa51. Current main now pins apache-arrow to 18.1.0, regenerates the memory-lancedb shrinkwrap, and carries the matching root lockfile resolution. The canonical issue #90295 closed when that trusted maintainer replacement merged.

The currently published npm latest package still carries the old dependency pair as of today, so release publication remains follow-through work; it is no longer implementation work for this PR. Thanks for supplying the correct fix and proof.