fix(macos): document Darwin kernel version fallback for macOS 26+#95161
fix(macos): document Darwin kernel version fallback for macOS 26+#95161ajwan8998 wants to merge 17 commits into
Conversation
drive list and drive info only checked the first page of results (default page size 10). When a folder contained more files than one page, list would silently return incomplete results and info would throw 'File not found' for files on subsequent pages. Fix: - listFolder: add pagination loop with has_more/next_page_token - getFileInfo: search across all pages using pagination - drive-schema: add page_size, page_token, all parameters to list action Closes: openclaw#93928 Co-Authored-By: Claude <[email protected]>
Co-Authored-By: Claude <[email protected]>
Co-Authored-By: Claude <[email protected]>
Co-Authored-By: Claude <[email protected]>
Co-Authored-By: Claude <[email protected]>
…60617t082059-002-20260617a (1)
Co-Authored-By: Claude <[email protected]>
Co-Authored-By: Claude <[email protected]>
Co-Authored-By: Claude <[email protected]>
Co-Authored-By: Claude <[email protected]>
Add MAX_LIST_PAGES cap (100) to the all-pages pagination loop so a repeated or missing next_page_token from the Feishu API does not cause unbounded requests.
|
Thanks for the contribution. I reviewed the branch, and this PR is not a good landing base for OpenClaw. Close as low-signal/unmergeable: the branch now mixes a separate Feishu Drive pagination PR into a macOS Tahoe fallback change, and the macOS portion still does not fix the linked runtime metadata problem. So I’m closing this PR rather than keeping an unmergeable branch open. A new narrow PR that carries only the useful part is welcome. Review detailsBest possible solution: Close this mixed branch and keep narrow review lanes: Feishu pagination in the dedicated Feishu PR, and the macOS Tahoe runtime metadata fix in a focused candidate for the canonical macOS issue. Do we have a high-confidence way to reproduce the issue? Yes. Source inspection shows the macOS runtime prompt paths still use Is this the best way to solve the issue? No. The best fix is not one mixed branch; macOS needs a focused runtime prompt product-version fix, while Feishu pagination should stay in its dedicated plugin PR with live proof or an explicit proof override. Security review: Security review cleared: No concrete security or supply-chain concern was found; the diff does not change dependencies, workflows, secrets, permissions, package scripts, or credential handling. AGENTS.md: found and applied where relevant. What I checked:
Likely related people:
Codex review notes: model internal, reasoning high; reviewed against 6bfe7a2b06cf. |
When sw_vers -productVersion is unavailable (CI, containers), derive the macOS version from the Darwin kernel major version using the known mapping (Darwin 12-24 = macOS major - 9). Darwin 25+ (macOS 26 Tahoe) no longer follows this formula, so return the raw kernel version. Fixes openclaw#95145
7779134 to
6a0d688
Compare
|
ClawSweeper applied the proposed close for this PR.
|
Fixes #95145
Summary
When
sw_vers -productVersionis unavailable (CI, containers), the macOS version fallback returns the raw Darwin kernel version (e.g.25.5.0) which does not correspond to any macOS marketing version. Darwin 25 corresponds to macOS 26 (Tahoe), but the old formula (Darwin - 9 = macOS major) would incorrectly give macOS 16.Changes
src/infra/os-summary.ts: Derive macOS version from Darwin kernel major whensw_versis unavailablesrc/infra/system-presence.ts: Same fallback fixReal behavior proof
Behavior addressed: Darwin kernel version now maps to correct macOS version in the fallback path.
After-fix evidence:
What was not tested: On actual macOS 26 Tahoe where
sw_versis available (the primary code path works correctly).Risk
Closes: #95145