fix: reject incompatible Node 23 runtimes#99832
Conversation
Dependency GuardThis PR changes dependency-related files. Maintainers should confirm these changes are intentional. Changed files:
Maintainer follow-up:
|
Dependency graph change authorizedThis PR includes dependency graph changes. A repository admin or member of
A later push changes the PR head SHA and requires a fresh security approval. |
|
Codex review: needs maintainer review before merge. Reviewed July 4, 2026, 2:58 AM ET / 06:58 UTC. Summary Reproducibility: yes. from source and related reports: current main accepts Node 23.0-23.10 through package and launcher checks while SQLite state helpers call Review metrics: 1 noteworthy metric.
Stored data model Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Land this direction only with maintainer acceptance of the fail-closed Node 23.0-23.10 contract; otherwise replace it with a shared SQLite compatibility fallback that keeps that interval supported. Do we have a high-confidence way to reproduce the issue? Yes from source and related reports: current main accepts Node 23.0-23.10 through package and launcher checks while SQLite state helpers call Is this the best way to solve the issue? Yes if maintainers choose early rejection over preserving EOL Node 23.0-23.10 support. The safer alternative, if that interval remains supported, is a shared SQLite/Kysely compatibility fallback instead of a fail-closed runtime contract. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 29814252e8e3. Label changesLabel justifications:
Evidence reviewedWhat I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
|
/allow-dependencies-change |
|
/allow-dependencies-change |
1 similar comment
|
/allow-dependencies-change |
|
Maintainer review: land-ready.
No remaining proof gap or blocker. |
|
Merged via squash.
|
* fix: reject incompatible Node 23 runtimes * fix: repair installer CI coverage * docs: clarify supported Node ranges * fix: fail closed on unreadable runtime versions --------- Co-authored-by: Peter Steinberger <[email protected]>
Summary
node:sqlitestatement API before accepting an existing runtimeRelated to #90007.
Verification
bash -n scripts/install.sh scripts/install-cli.shopenclaw.aibranchcorepack pnpm check:changed:run_a9d4d7aef036corepack pnpm build:run_29b2b32b3865$autoreview --mode branch --base upstream/main: clean, no accepted/actionable findingsThe macOS Swift unit suite could not run locally because the package requires Swift 6.2 and the installed toolchain is Swift 6.0; the RuntimeLocator boundary tests are included for CI.
Real behavior proof
Behavior addressed: OpenClaw could install successfully on Node 23.0-23.10, then fail at startup or during state migration because those releases do not expose the required
StatementSync.columns()API.Real environment tested: macOS with official Node 22.19, 23.7, 23.11, and 24 runtimes; Linux on AWS Crabbox for changed checks and build.
Exact steps or command run after this patch: launched
openclaw.mjs --versionunder each Node runtime, ran the focused Vitest boundary matrix, and ran the installer shell probes for the same version boundaries.Evidence after fix: Node 23.7 is rejected before OpenClaw startup with an actionable runtime-range message; Node 22.19, Node 23.11, and Node 24 proceed successfully.
Observed result after fix: the unsupported Node interval can no longer reach the SQLite-backed runtime paths that trigger
statement.columns is not a function.What was not tested: the macOS Swift unit suite locally due to the Swift 6.2 toolchain requirement.