fix: strengthen macOS SQLite WAL checkpoint durability by ooiuuii · Pull Request #99067 · openclaw/openclaw

ooiuuii · 2026-07-02T12:02:00Z

What Problem This Solves

Fixes an issue where macOS users could run OpenClaw SQLite WAL checkpoints without SQLite's macOS fullfsync checkpoint barrier enabled. The normal app behavior would not show an error, but recently checkpointed local state could be less durable than intended across abrupt power loss or OS crashes.

Why This Change Was Made

This change enables PRAGMA checkpoint_fullfsync = 1; after WAL mode is turned on, only on macOS. The PRAGMA is treated as a best-effort durability upgrade: if a SQLite build rejects it, WAL setup continues with the existing autocheckpoint and rollback-on-unsupported-filesystem behavior.

User Impact

Mac users get stronger SQLite WAL checkpoint durability without changing configuration. Linux and Windows behavior is unchanged, and older SQLite builds that do not support the PRAGMA continue to open and configure their stores normally.

Evidence

Live macOS runtime proof from a real Node SQLite process on macOS 13.7.8, running this PR branch (aa10f1dd2f58723d5c9769de52086115c1a308b9):

platform=darwin
macos=13.7.8
node=v22.22.0
branch=proof/sqlite-macos-checkpoint-fullfsync
head=aa10f1dd2f58723d5c9769de52086115c1a308b9
journal_mode=wal
checkpoint_fullfsync=1
wal_autocheckpoint=1000
maintenance_checkpoint=true
maintenance_close=true
(node:76412) ExperimentalWarning: SQLite is an experimental feature and might change at any time

The live probe created a temporary SQLite database, called configureSqliteConnectionPragmas(db, { databasePath, checkpointIntervalMs: 0 }), then queried:

PRAGMA journal_mode;
PRAGMA checkpoint_fullfsync;
PRAGMA wal_autocheckpoint;

The observed checkpoint_fullfsync=1 confirms the macOS PRAGMA is applied in a real SQLite process after WAL setup.

Additional validation:

Source-level before condition: configureSqliteWalMaintenance enabled journal_mode = WAL and wal_autocheckpoint, but had no macOS branch for checkpoint_fullfsync.
Added focused coverage that mocks process.platform to darwin and verifies WAL setup calls PRAGMA checkpoint_fullfsync = 1; immediately after enabling WAL mode.
Added fallback coverage that makes the macOS checkpoint_fullfsync PRAGMA throw and verifies WAL setup continues to wal_autocheckpoint.
Existing rollback/NFS/network-filesystem behavior remains pinned by the same sqlite-wal.test.ts suite with explicit non-macOS platform mocks where needed.
node scripts\run-vitest.mjs src/infra/sqlite-wal.test.ts -> 1 file passed, 34 tests passed.
pnpm exec oxlint src/infra/sqlite-wal.ts src/infra/sqlite-wal.test.ts
pnpm exec oxfmt --check src/infra/sqlite-wal.ts src/infra/sqlite-wal.test.ts
git diff --check HEAD~1..HEAD
Repo-local autoreview: python .agents\skills\autoreview\scripts\autoreview --mode commit --commit HEAD -> autoreview clean: no accepted/actionable findings reported.

clawsweeper · 2026-07-02T12:05:19Z

Codex review: needs maintainer review before merge. Reviewed July 3, 2026, 1:54 AM ET / 05:54 UTC.

Summary
The PR adds a macOS-only best-effort SQLite checkpoint_fullfsync PRAGMA during shared WAL setup and focused tests for ordering and fallback behavior.

PR surface: Source +14, Tests +48. Total +62 across 2 files.

Reproducibility: yes. Current main source calls journal_mode and wal_autocheckpoint without checkpoint_fullfsync; I did not run a current-main macOS crash or power-loss repro, so this is source-reproducible rather than live-reproduced.

Review metrics: 1 noteworthy metric.

SQLite runtime default: 1 macOS-only PRAGMA added; 0 config/schema changes. The change strengthens checkpoint durability without adding migration or operator configuration surface, so review focuses on runtime proof and shared-helper ownership.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #99066
Summary: This PR is the direct implementation candidate for the linked open macOS SQLite WAL checkpoint_fullfsync issue; the other WAL durability PR is adjacent but distinct.

Members:

canonical: [Bug]: macOS SQLite WAL checkpoints skip fullfsync barriers #99066 - The PR body uses closing syntax for this open issue and both target the same missing macOS checkpoint_fullfsync branch in the shared SQLite WAL helper.
adjacent_distinct: fix(memory-core): checkpoint WAL after publishing index metadata #92509 - This open PR also concerns WAL durability, but it targets memory metadata checkpoint timing rather than the shared macOS checkpoint fullfsync barrier.

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

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

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

Rank-up moves:

none.

Next step before merge

No ClawSweeper repair lane is needed because this branch is already the active fix candidate and I found no narrow actionable defect.

Security
Cleared: The diff only changes SQLite PRAGMA setup and focused tests; it does not touch CI, dependencies, secrets, permissions, package resolution, or other supply-chain surfaces.

Review details

Best possible solution:

Land the shared WAL-helper fix after routine maintainer review; the linked issue should close through the merge.

Do we have a high-confidence way to reproduce the issue?

Yes. Current main source calls journal_mode and wal_autocheckpoint without checkpoint_fullfsync; I did not run a current-main macOS crash or power-loss repro, so this is source-reproducible rather than live-reproduced.

Is this the best way to solve the issue?

Yes. The shared WAL helper is the narrow owner boundary, the PR avoids a new config knob, and per-caller changes or global fullfsync would be broader than the checkpoint-specific durability gap.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against c5afa92c1f8a.

Label changes

Label justifications:

P2: The PR addresses a bounded macOS SQLite state-durability bug with limited platform scope and no evidence of an active outage.
rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (terminal): The PR body includes after-fix macOS terminal output from a real Node SQLite process at the PR head showing WAL enabled with checkpoint_fullfsync=1.
proof: sufficient: Contributor real behavior proof is sufficient. The PR body includes after-fix macOS terminal output from a real Node SQLite process at the PR head showing WAL enabled with checkpoint_fullfsync=1.

Evidence reviewed

PR surface:

Source +14, Tests +48. Total +62 across 2 files.

View PR surface stats

Area	Files	Added	Net
Source	1	14	+14
Tests	1	48	+48
Docs	0	0	0
Config	0	0	0
Generated	0	0	0
Other	0	0	0
Total	2	62	+62

What I checked:

Repository policy read: Root AGENTS.md was read fully; its deep PR review, dependency-contract, read-only, and SQLite/storage guidance affected this review. (AGENTS.md:1, c5afa92c1f8a)
No scoped infra AGENTS.md: find showed scoped AGENTS.md files under src, but none owns src/infra, so root policy is the applicable repository-authored policy for the touched files. (c5afa92c1f8a)
Current main still lacks the macOS checkpoint barrier: configureSqliteWalMaintenance on current main enables WAL and wal_autocheckpoint with no checkpoint_fullfsync branch or fullfsync-related code. (src/infra/sqlite-wal.ts:314, c5afa92c1f8a)
Latest release also lacks the fix: v2026.6.11 has the same journal_mode/WAL autocheckpoint setup and no checkpoint_fullfsync call, so this PR is not obsolete on shipped code. (src/infra/sqlite-wal.ts:314, e085fa1a3ffd)
PR implementation is in the shared owner path: The PR branch adds enableMacosCheckpointFullfsync, gates it to darwin, treats failures as non-fatal, and calls it immediately after WAL mode is enabled before wal_autocheckpoint setup. (src/infra/sqlite-wal.ts:277, aa10f1dd2f58)
Focused tests cover the changed behavior: The PR adds tests for macOS call order and for continuing WAL setup when checkpoint_fullfsync throws. (src/infra/sqlite-wal.test.ts:55, aa10f1dd2f58)

Likely related people:

vincentkoc: Recent GitHub history shows multiple SQLite WAL and storage-safety changes in the shared helper and adjacent tests, including network-filesystem and SSHFS policy. (role: recent area contributor; confidence: high; commits: 00160ea6ee22, ac8a3f367c32, b470316fc0af; files: src/infra/sqlite-wal.ts, src/infra/sqlite-wal.test.ts, src/state/openclaw-state-db.ts)
steipete: History shows shared SQLite state database work and WAL checkpoint interval hardening on the same local state/checkpointing surface. (role: adjacent storage owner; confidence: medium; commits: bc848b367f0b, 287f531de6c4, 3bc29dd60448; files: src/infra/sqlite-wal.ts, src/infra/sqlite-wal.test.ts, src/state/openclaw-state-db.ts)
honor2030: Recent history shows the periodic checkpoint mode change that shaped configureSqliteWalMaintenance checkpoint behavior and tests. (role: checkpoint behavior contributor; confidence: medium; commits: 1a2e41850092; files: src/infra/sqlite-wal.ts, src/infra/sqlite-wal.test.ts)
849261680: Authored the earlier NFS/WAL helper change that centralized database path context and WAL policy for core, memory, and proxy-capture callers. (role: shared WAL helper contributor; confidence: medium; commits: 5b21a0337bbe; files: src/infra/sqlite-wal.ts, src/infra/sqlite-wal.test.ts)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

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

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

ooiuuii · 2026-07-02T13:11:55Z

@clawsweeper re-review

I updated the Evidence section with live macOS terminal output from a real Node SQLite process on macOS 13.7.8 showing checkpoint_fullfsync=1 after configureSqliteConnectionPragmas runs on this PR branch.

clawsweeper · 2026-07-02T13:11:58Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

ooiuuii · 2026-07-03T03:27:15Z

@clawsweeper re-review

Current PR body already includes live macOS runtime proof from a real Node SQLite process on macOS 13.7.8 at this PR head, showing platform=darwin, journal_mode=wal, and checkpoint_fullfsync=1 after configureSqliteConnectionPragmas(...) runs. It also lists the focused WAL tests and static checks.

* fix: gate diagnostics command to owners (cherry picked from commit 170bf72) * fix(agent): replace self-wait with deferred release in retained-lock abort cleanup (#96100) * fix(agent): wait for retained session write before releasing held lock on abort * fix(agent): replace self-wait with deferred release in retained-lock abort cleanup * fix(test): reject fallback acquire with SessionWriteLockTimeoutError in active-scope cleanup test * fix(agent): trim retained-lock comments Signed-off-by: sallyom <[email protected]> --------- Signed-off-by: sallyom <[email protected]> Co-authored-by: sallyom <[email protected]> (cherry picked from commit 0a042f6) * fix(gateway): resume channel after pending task recovery (cherry picked from commit 6039da3) * fix(gateway): resume channel after pending task recovery (cherry picked from commit ecd29fe) * fix(outbound): ignore empty delivery receipts (#79811) (cherry picked from commit 9a735be) * fix(agents): guard delivery-evidence attachment recursion against cycles (#97041) * fix(agents): guard delivery-evidence attachment recursion against cycles * fix(agents): guard delivery-evidence attachment recursion against cycles * fix(agents): guard delivery-evidence attachment recursion against cycles --------- Co-authored-by: Pick-cat <[email protected]> Co-authored-by: Vincent Koc <[email protected]> (cherry picked from commit 4985671) * fix(opencode-go): re-arm idle timer on block-boundary events to prevent false stalled-stream abort (#97128) * fix(opencode-go): re-arm idle timer on block-boundary events to prevent false stalled-stream abort When the opencode-go model finalizes a tool call and deliberates before the next one, the provider emits real block-boundary SSE events (text_end, thinking_end, toolcall_start, toolcall_end) that prove the socket is alive, but the watchdog's isProviderProgressEvent only returned true for token deltas (text_delta, thinking_delta, toolcall_delta). This caused the idle timer to fire and falsely abort a live stream, replacing a completed answer with a stalled error and dropping the provider's real done event. Fix: include block-boundary events in isProviderProgressEvent so the idle timer is re-armed on any forward-progress provider event. text_start and thinking_start are intentionally excluded because they are synthetic preamble events that should not shorten the first-event window. Closes #96518 Co-Authored-By: Claude Opus 4.8 <[email protected]> * test(opencode-go): satisfy lint in stream regression * test(opencode-go): satisfy lint in stream regression * test(opencode-go): satisfy lint in stream regression --------- Co-authored-by: Claude Opus 4.8 <[email protected]> Co-authored-by: Vincent Koc <[email protected]> (cherry picked from commit 552ec2b) * fix(model-fallback): don't rethrow provider-side AbortErrors as user cancellations (#90908) * fix(model-fallback): don't rethrow provider-side AbortErrors as user cancellations When the LLM API closes the connection mid-stream, the fetch layer surfaces AbortError("This operation was aborted") with no external abort signal triggered. The old guard `shouldRethrowAbort()` returned false for these errors (because isTimeoutError matched the message), so they fell through to the fallback loop but were never retried — the error propagated up and produced SILENT_REPLY_TOKEN in group sessions, permanently silencing the topic. Replace the guard with a direct check: only rethrow AbortError when the external abort signal is actually set (user/gateway cancellation). Provider-side AbortErrors without an external signal now fall through to the next fallback candidate, giving the system a chance to recover. * fix(cron): forward abort signal into runWithModelFallback Thread the cron executor's abort signal into the shared runWithModelFallback call so that cron timeouts and cancellations stop the fallback chain instead of retrying with the next candidate. Previously, the run callback checked params.abortSignal?.aborted and threw, but runWithModelFallback itself had no signal — so the new guard in model-fallback.ts could not distinguish a caller abort from a provider-side AbortError and would retry silently. Also adds a focused regression test verifying the signal is forwarded. --------- Co-authored-by: Shengting Xie <[email protected]> Co-authored-by: yayu <[email protected]> (cherry picked from commit 98ed83f) * fix(browser): block node routes when sandbox host control is disabled (#97958) (cherry picked from commit 2cf765f) * fix(exec): bind Windows allowlist execution path (#98260) * fix(exec): bind windows allowlist execution path * fix(exec): add windows shadow execution proof * fix(exec): preserve wildcard allowlist behavior * fix(exec): correct blocked plan test fixture (cherry picked from commit 3811001) * fix(mcp): suppress unhandled error on stderr pipe in stdio transport (#99803) * fix(mcp): suppress unhandled error on stderr pipe in stdio transport When child.stderr is piped to stderrStream without an error handler, a stream-level error (EPIPE, I/O failure) crashes the process. Add a noop error handler before the pipe, consistent with the error handlers already present on stdin and stdout. Co-Authored-By: Claude <[email protected]> * test(mcp): add regression test for stderr pipe error suppression Co-Authored-By: Claude <[email protected]> * fix(mcp): report stderr stream errors * fix(mcp): report stderr stream errors --------- Co-authored-by: Claude <[email protected]> Co-authored-by: Vincent Koc <[email protected]> (cherry picked from commit 1b84316) * Harden macOS SQLite WAL checkpoints (#99067) (cherry picked from commit f7f1be2) * fix(secrets): suppress unhandled stdout/stderr stream errors in exec resolver (#100521) * fix(secrets): suppress unhandled stdout/stderr stream errors in exec resolver * proof(secrets): add real behavior proof script for exec resolver stream error catch * proof(secrets): replace wrapper with real exec resolver stream error proof * style: apply oxfmt to changed files (cherry picked from commit c9a0783) * fix(agents): retry transient filesystem races when reading workspace bootstrap files (#100910) * fix(agents): retry transient filesystem races when reading workspace bootstrap files * fix(agents): retry transient boundary resolution --------- Co-authored-by: Vincent Koc <[email protected]> (cherry picked from commit f36d170) * fix(gateway): finish plugin HTTP responses after post-header failures (#102125) * fix(gateway): finish plugin HTTP responses after post-header failures * test(gateway): satisfy plugin HTTP regression lint * fix(gateway): skip ending destroyed plugin responses --------- Co-authored-by: Peter Steinberger <[email protected]> (cherry picked from commit 240d350) * fix(gateway): validate exact custom browser origins (#38290) Co-authored-by: Peter Steinberger <[email protected]> (cherry picked from commit fa0349a) * fix: block unspecified trusted DNS targets (#103075) (cherry picked from commit c70f3d0) * fix(channels): make nack callbacks idempotent (#104919) * fix(channels): make nack callbacks idempotent * fix(channels): coalesce overlapping nack callbacks --------- Co-authored-by: Peter Steinberger <[email protected]> (cherry picked from commit 02d307e) * fix(channels): prevent base URL credentials in status output (#107754) * fix(channels): redact credentials in account URLs * fix(channels): sanitize final status summaries (cherry picked from commit 210340f) * fix(channels): prevent lifecycle listener buildup (#109108) (cherry picked from commit 0e1fad7) * fix(sandbox): use Buffer.byteLength for env var value size limit (#105017) * fix(sandbox): use Buffer.byteLength for env var value size limit validateEnvVarValue checked value.length (UTF-16 code units) against the 32768-byte limit, so multi-byte CJK values like "值".repeat(11000) passed the check despite exceeding 33 KB in UTF-8. Switch to Buffer.byteLength(value, "utf8") so the limit matches the actual byte count the OS and child processes see. * test(sandbox): simplify env byte-limit coverage Co-authored-by: 唐梓夷0668001293 <[email protected]> --------- Co-authored-by: Peter Steinberger <[email protected]> (cherry picked from commit 84fb48c) * fix(gateway): guard process.kill ESRCH race in signalVerifiedGatewayPidSync (#109590) * fix(gateway): guard process.kill ESRCH race in signalVerifiedGatewayPidSync A verified gateway process can exit between the argv validation check and the process.kill call, causing an unhandled ESRCH error. Wrap the kill in try-catch and silently swallow ESRCH (process already gone = signal already delivered). Co-Authored-By: Claude Sonnet 4.6 <[email protected]> * docs(gateway): explain ESRCH signal race Co-authored-by: 丁宇婷0668001435 <[email protected]> --------- Co-authored-by: Claude Sonnet 4.6 <[email protected]> Co-authored-by: Peter Steinberger <[email protected]> (cherry picked from commit 853b1a8) * fix(litellm): guard loopback hostname auto-allow with isIP to prevent DNS SSRF bypass (#110693) * fix(litellm): guard loopback hostname auto-allow with isIP to prevent DNS bypass The isAutoAllowedLitellmHostname helper auto-enables private-network access for loopback-style hosts. Before this fix, lowered.startsWith("127.") matched DNS hostnames like 127.evil.com, letting remote endpoints bypass the explicit allowPrivateNetwork opt-in — a SSRF risk. Add isIP(host)===4 guard so only literal IPv4 loopback addresses qualify. Same canonical pattern as extensions/slack/src/monitor/relay-source.ts:271 and the codex loopback fix. Co-Authored-By: Claude <[email protected]> * test(litellm): cover loopback endpoint policy --------- Co-authored-by: Claude <[email protected]> Co-authored-by: Peter Steinberger <[email protected]> (cherry picked from commit 3d03b60) * fix(discord): sustained gateway bursts stop growing memory (#110954) * fix(discord): sustained gateway bursts stop growing memory * fix(discord): contain gateway queue overflow * fix(discord): drop oldest saturated gateway sends Co-authored-by: 张贵萍0668001030 <[email protected]> * fix(discord): surface gateway overflow warnings Co-authored-by: 张贵萍0668001030 <[email protected]> --------- Co-authored-by: Peter Steinberger <[email protected]> (cherry picked from commit 69aeba9) * fix(gateway): bound busy channel health by real run age (#103793) * fix(gateway): bound busy channel health by real run age The channel health policy treats a channel as healthy-busy even while disconnected, bounded only by a 25 minute stale ceiling measured from lastRunActivityAt. The run-state heartbeat refreshes lastRunActivityAt every 60 seconds for as long as any run is active, so a run that hangs forever (for example a send blocking on a dead socket after the transport already reported connected:false) keeps that timestamp fresh and the stuck ceiling is never reached. The account is then reported healthy forever by the health monitor, readiness probe, and health CLI, and no restart ever fires. createRunStateMachine now tracks each in-flight run's start time keyed by an opaque run handle and publishes the oldest still-active run's start as activeRunStartedAt. The health policy busy override keys its ceiling off the real run age, so a run stuck longer than the threshold reports stuck and the monitor can restart it. Because the reported start is the oldest active run and advances to the next-oldest as runs complete, a channel churning through many short overlapping runs (activeRuns above 1 across concurrent queue keys) stays healthy; only a genuinely hung run breaches the ceiling. Short and active runs stay healthy and the existing lastRunActivityAt fallback is preserved for snapshots without a start time. * fix(channels): retain run-state callback compatibility Keep the released zero-argument onRunEnd callback source-compatible while allowing internal queue callers to pass a run handle for exact concurrent-run accounting. The compatibility path closes the oldest active run, preserving existing lifecycle behavior for consumers that do not use handles. * fix(channels): keep anonymous runs out of age tracking The zero-argument lifecycle callbacks cannot identify which concurrent run completed, so they must not update the identity-sensitive run start used by channel health. Keep their busy count separately and reserve exact start tracking for the shared queue's handle-aware lifecycle path. * fix(channels): keep tracked runs internal Keep the public run-state lifecycle callbacks unchanged. The channel queue now owns opaque run identity and augments its status updates with the oldest active queue run, so implementation details do not expand the SDK surface. * fix(channels): type queue run start status Keep activeRunStartedAt in the internal status patch type so the queue can publish its private tracked-run age through the existing status sink. * fix(channels): wrap isActive to satisfy unbound-method lint * fix(gateway): gate busy run-age ceiling on disconnected transport (cherry picked from commit 18b79d9) * fix(deps): update fast-uri past advisory (cherry picked from commit 1be9db0) * fix(release): adapt maintenance-line hardening Backport/adapt 18ec9ce, dea1fe1, 7f32b6c, 1da345e, 931ac3e, 89780d5, and c0d99ed for the 2026.6 extended-stable maintenance line. * fix(deps): bump protobufjs to 7.6.5 Backport-adapted from a230f74. * test(gateway): cover bounded macOS process probe * chore(release): prepare 2026.6.34 * test(dotenv): share path override environment assertions * fix(release): resolve 2026.6.34 CI blockers --------- Signed-off-by: sallyom <[email protected]> Co-authored-by: joshavant <[email protected]> Co-authored-by: Peter Lee <[email protected]> Co-authored-by: sallyom <[email protected]> Co-authored-by: openclaw-clownfish[bot] <280122609+openclaw-clownfish[bot]@users.noreply.github.com> Co-authored-by: Liu Wenyu <[email protected]> Co-authored-by: pick-cat <[email protected]> Co-authored-by: Pick-cat <[email protected]> Co-authored-by: Vincent Koc <[email protected]> Co-authored-by: weiqinl <[email protected]> Co-authored-by: Claude Opus 4.8 <[email protected]> Co-authored-by: shengting <[email protected]> Co-authored-by: Shengting Xie <[email protected]> Co-authored-by: yayu <[email protected]> Co-authored-by: Agustin Rivera <[email protected]> Co-authored-by: cxbAsDev <[email protected]> Co-authored-by: ooiuuii <[email protected]> Co-authored-by: Masato Hoshino <[email protected]> Co-authored-by: Vincent Koc <[email protected]> Co-authored-by: mushuiyu886 <[email protected]> Co-authored-by: Peter Steinberger <[email protected]> Co-authored-by: Bruno Wowk (Volky) <[email protected]> Co-authored-by: Pavan Kumar Gondhi <[email protected]> Co-authored-by: Glucksberg <[email protected]> Co-authored-by: xingzhou <[email protected]> Co-authored-by: tzy-17 <[email protected]> Co-authored-by: krissding <[email protected]> Co-authored-by: lsr911 <[email protected]> Co-authored-by: Yuval Dinodia <[email protected]>

Harden macOS SQLite WAL checkpoints

aa10f1d

openclaw-barnacle Bot added the size: S label Jul 2, 2026

clawsweeper Bot mentioned this pull request Jul 2, 2026

[Bug]: macOS SQLite WAL checkpoints skip fullfsync barriers #99066

Closed

openclaw-clownfish Bot merged commit f7f1be2 into openclaw:main Jul 6, 2026
203 of 222 checks passed

vincentkoc mentioned this pull request Jul 6, 2026

chore(jobs): prune resolved OpenClaw inbox jobs openclaw/clownfish#221

Merged

github-actions Bot pushed a commit to Desicool/openclaw that referenced this pull request Jul 6, 2026

Harden macOS SQLite WAL checkpoints (openclaw#99067)

0d9324c

jarvis1982oc mentioned this pull request Jul 7, 2026

CLI startup preflight can corrupt the live state DB while a gateway is running — health-check commands caused "database disk image is malformed" (2026.6.6, macOS); vanilla SQLite control does NOT reproduce #101290

Open

giodl73-repo pushed a commit to giodl73-repo/openclaw that referenced this pull request Jul 8, 2026

Harden macOS SQLite WAL checkpoints (openclaw#99067)

1bf8fb3

clawsweeper Bot mentioned this pull request Jul 17, 2026

fix(infra): bound filesystem mount table probes #109448

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix: strengthen macOS SQLite WAL checkpoint durability#99067

fix: strengthen macOS SQLite WAL checkpoint durability#99067
openclaw-clownfish[bot] merged 1 commit into
openclaw:mainfrom
ooiuuii:fix/sqlite-macos-checkpoint-fullfsync

ooiuuii commented Jul 2, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jul 2, 2026 •

edited

Loading

Uh oh!

ooiuuii commented Jul 2, 2026

Uh oh!

clawsweeper Bot commented Jul 2, 2026 •

edited

Loading

Uh oh!

ooiuuii commented Jul 3, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

ooiuuii commented Jul 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What Problem This Solves

Why This Change Was Made

User Impact

Evidence

Uh oh!

clawsweeper Bot commented Jul 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ooiuuii commented Jul 2, 2026

Uh oh!

clawsweeper Bot commented Jul 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ooiuuii commented Jul 3, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

ooiuuii commented Jul 2, 2026 •

edited

Loading

clawsweeper Bot commented Jul 2, 2026 •

edited

Loading

clawsweeper Bot commented Jul 2, 2026 •

edited

Loading