openclaw - ✅(Solved) Fix WhatsApp creds.json corruption every ~30 minutes (non-atomic write) [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#63496Fetched 2026-04-09 07:53:05
View on GitHub
Comments
1
Participants
2
Timeline
2
Reactions
0
Timeline (top)
commented ×1cross-referenced ×1

WhatsApp creds.json is being corrupted approximately every 30 minutes during Baileys session save operations. OpenClaw detects and auto-restores from backup, but each restore triggers a WhatsApp reconnect causing message delays and dropped messages.

Error Message

2026-04-09T00:27:04.018+00:00 [WARN] {module:web-session} restored corrupted WhatsApp creds.json from backup
2026-04-09T00:57:08.135+00:00 [WARN] {module:web-session} restored corrupted WhatsApp creds.json from backup

Corruption timestamps show ~30 min interval pattern consistently.

Root Cause

WhatsApp creds.json is being corrupted approximately every 30 minutes during Baileys session save operations. OpenClaw detects and auto-restores from backup, but each restore triggers a WhatsApp reconnect causing message delays and dropped messages.

Fix Action

Fixed

PR fix notes

PR #63520: fix(whatsapp): atomic write-back for creds.json after Baileys save

Description (problem / solution / changelog)

Closes #63496

Summary

  • add an atomic write-back step after every Baileys saveCreds() call
  • re-reads the just-written creds.json, validates JSON integrity, then atomically rewrites via tmp + rename
  • prevents partial/interrupted Baileys writes from leaving a corrupted file on disk

Root cause

Baileys' useMultiFileAuthState writes creds.json with a plain writeFileSync, which is not atomic. If the process is interrupted mid-write (crash, signal, disk I/O stall), the file can be left truncated or empty. OpenClaw already detects and restores from backup, but each restore triggers a WhatsApp reconnect causing message delays.

Test plan

  • existing WhatsApp session tests pass (11/12, the 1 failure pre-exists on main and is unrelated to this change)
  • node scripts/run-vitest.mjs run --config vitest.extension-whatsapp.config.ts extensions/whatsapp/src/session.test.ts

Changed files

  • extensions/whatsapp/src/session.ts (modified, +28/-4)

Code Example

fs.writeFileSync(credsPath, JSON.stringify(creds))

---

const tmp = credsPath + '.tmp'
fs.writeFileSync(tmp, JSON.stringify(creds))
fs.renameSync(tmp, credsPath)

---

2026-04-09T00:27:04.018+00:00 [WARN] {module:web-session} restored corrupted WhatsApp creds.json from backup
2026-04-09T00:57:08.135+00:00 [WARN] {module:web-session} restored corrupted WhatsApp creds.json from backup
RAW_BUFFERClick to expand / collapse

Description

WhatsApp creds.json is being corrupted approximately every 30 minutes during Baileys session save operations. OpenClaw detects and auto-restores from backup, but each restore triggers a WhatsApp reconnect causing message delays and dropped messages.

Evidence

  • 49 corruptions in 24 hours (2026-04-08)
  • Pattern matches Baileys session save interval (~30 min)
  • Log warning: restored corrupted WhatsApp creds.json from backup
  • File path: ~/.openclaw/credentials/whatsapp/default/creds.json

Environment

  • OpenClaw: 2026.4.8 (9ece252)
  • OS: Linux 6.12.73+deb13-amd64
  • Node: v22.22.1
  • Disk: plenty of space (148G free), no I/O issues

Expected Behavior

creds.json should be written atomically (write to temp file → rename()) to prevent corruption during saves.

Suggested Fix

In auth-store (or wherever Baileys creds are persisted), replace:

fs.writeFileSync(credsPath, JSON.stringify(creds))

with:

const tmp = credsPath + '.tmp'
fs.writeFileSync(tmp, JSON.stringify(creds))
fs.renameSync(tmp, credsPath)

This ensures the file is always either the old version or the new version, never a partial write.

Logs

2026-04-09T00:27:04.018+00:00 [WARN] {module:web-session} restored corrupted WhatsApp creds.json from backup
2026-04-09T00:57:08.135+00:00 [WARN] {module:web-session} restored corrupted WhatsApp creds.json from backup

Corruption timestamps show ~30 min interval pattern consistently.

extent analysis

TL;DR

Replace the synchronous file write operation in the auth-store with an atomic write approach to prevent creds.json corruption during Baileys session save operations.

Guidance

  • Verify that the auth-store module is indeed using fs.writeFileSync to save the creds.json file, and that this is the only place where the file is being written.
  • Implement the suggested fix by replacing the fs.writeFileSync call with the atomic write approach using a temporary file and fs.renameSync.
  • Monitor the logs for the restored corrupted WhatsApp creds.json from backup warning to ensure that the corruption issue is resolved after applying the fix.
  • Consider adding additional logging or metrics to track the frequency of creds.json corruptions and verify that the issue is fully resolved.

Example

const tmp = credsPath + '.tmp'
fs.writeFileSync(tmp, JSON.stringify(creds))
fs.renameSync(tmp, credsPath)

Notes

This fix assumes that the corruption issue is solely due to the non-atomic write operation. If the issue persists after applying this fix, further investigation may be needed to identify other potential causes.

Recommendation

Apply the suggested workaround using the atomic write approach, as it directly addresses the identified root cause of the corruption issue and ensures that the creds.json file is always written consistently.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING