Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix WhatsApp: false-positive 'restored corrupted creds.json from backup' on every startup/reconnect [1 pull requests, 2 comments, 3 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#60625•Fetched 2026-04-08 02:49:03
View on GitHub
Comments
2
Participants
3
Timeline
5
Reactions
0
Author
cpicotocpicoto
Participants
cpicotocpicotonachtsheimnachtsheimzhuzhushiwojiazhuzhushiwojia
Timeline (top)
commented ×2cross-referenced ×2referenced ×1

On every gateway startup and WhatsApp reconnect, the log emits:

[WARN] [web-session] restored corrupted WhatsApp creds.json from backup

However, creds.json and creds.json.bak are byte-identical — there is no actual corruption. The detection logic in auth-store-*.js (maybeRestoreCredsFromBackup) appears to have a false-positive condition.

Error Message

[WARN] [web-session] restored corrupted WhatsApp creds.json from backup

  • When combined with the reconnect loop (see below), this generates hundreds of false warnings in the error log 2026-04-02T20:41:10.186-07:00 [WARN] [web-session] restored corrupted WhatsApp creds.json from backup 2026-04-02T20:42:14.402-07:00 [WARN] [web-session] restored corrupted WhatsApp creds.json from backup 2026-04-02T20:43:18.013-07:00 [WARN] [web-session] restored corrupted WhatsApp creds.json from backup

Root Cause

On every gateway startup and WhatsApp reconnect, the log emits:

[WARN] [web-session] restored corrupted WhatsApp creds.json from backup

However, creds.json and creds.json.bak are byte-identical — there is no actual corruption. The detection logic in auth-store-*.js (maybeRestoreCredsFromBackup) appears to have a false-positive condition.

Fix Action

Fixed

PR fix notes

PR #60650: fix(whatsapp): skip false-positive creds.json corruption restore

Description (problem / solution / changelog)

Summary

  • Fix false-positive "restored corrupted WhatsApp creds.json from backup" WARN log that fires on every startup/reconnect even when credentials are valid

Root Cause

File: extensions/whatsapp/src/auth-store.ts:36-65 Introduced in: 66dfe18 (fix(ci): avoid duplicate accountId spread) Function: maybeRestoreCredsFromBackup()

readCredsJsonRaw() returns null for both "file truly absent" and "file exists but is empty/truncated (size <= 1)". The latter is a transient state during concurrent saveCreds() writes by Baileys — writeFile truncates the file before writing new content. When maybeRestoreCredsFromBackup runs during this window (e.g. on reconnect after status 499), it sees the empty file, restores from backup, and emits a WARN — even though the file was never corrupted.

Fix

After readCredsJsonRaw returns null, add a statSync check to see whether the file still physically exists on disk. If it does (empty but present), the truncation is transient — skip the restore. Only restore from backup when statSync throws ENOENT (file truly absent).

Call path verified: createWaSocket() → maybeRestoreCredsFromBackup() (session.ts:116) runs before useMultiFileAuthState() on every reconnect. The fix is reachable at runtime.

G8 single-site check: maybeRestoreCredsFromBackup is the only function in the codebase that performs this restore logic (grep confirmed, no duplicates).

Test Plan

  • New auth-store.test.ts with 5 test cases:
    • Valid creds.json → no restore
    • Truly absent creds.json + valid backup → restore (correct behavior preserved)
    • Empty creds.json (transient write) + valid backup → no restore (bug fix)
    • Single-byte creds.json (transient write) + valid backup → no restore (bug fix)
    • Neither file exists → no-op
  • Existing session.test.ts (10 tests) still passes
  • Existing logout.test.ts (4 tests) still passes

Closes #60625

Changed files

  • extensions/whatsapp/src/auth-store.test.ts (added, +130/-0)
  • extensions/whatsapp/src/auth-store.ts (modified, +35/-0)

Code Example

[WARN] [web-session] restored corrupted WhatsApp creds.json from backup

---

2026-04-02T20:41:10.186-07:00 [WARN] [web-session] restored corrupted WhatsApp creds.json from backup
2026-04-02T20:42:14.402-07:00 [WARN] [web-session] restored corrupted WhatsApp creds.json from backup
2026-04-02T20:43:18.013-07:00 [WARN] [web-session] restored corrupted WhatsApp creds.json from backup
...repeats every ~60 seconds during reconnect loop
RAW_BUFFERClick to expand / collapse

Summary

On every gateway startup and WhatsApp reconnect, the log emits:

[WARN] [web-session] restored corrupted WhatsApp creds.json from backup

However, creds.json and creds.json.bak are byte-identical — there is no actual corruption. The detection logic in auth-store-*.js (maybeRestoreCredsFromBackup) appears to have a false-positive condition.

Observed Behavior

  • Every single WhatsApp connection (fresh start or reconnect after status 499) triggers this warning
  • diff creds.json creds.json.bak shows zero differences
  • creds.json is valid JSON with all expected fields
  • WhatsApp connects successfully after the "restore" — it is functionally harmless
  • When combined with the reconnect loop (see below), this generates hundreds of false warnings in the error log

Environment

  • OpenClaw: 2026.4.2
  • OS: macOS 25.3.0 (ARM64, Mac mini M1)
  • Node: v25.6.1
  • WhatsApp account type: Personal (linked device)

Expected Behavior

The corruption check should compare actual file content/validity rather than triggering unconditionally on startup. If the file is valid JSON with the expected schema, no warning should be emitted.

Log evidence

2026-04-02T20:41:10.186-07:00 [WARN] [web-session] restored corrupted WhatsApp creds.json from backup
2026-04-02T20:42:14.402-07:00 [WARN] [web-session] restored corrupted WhatsApp creds.json from backup
2026-04-02T20:43:18.013-07:00 [WARN] [web-session] restored corrupted WhatsApp creds.json from backup
...repeats every ~60 seconds during reconnect loop

Related

This is amplified by the reconnect storm issue (filed separately).

extent analysis

TL;DR

The false-positive warning for corrupted WhatsApp credentials can be addressed by modifying the detection logic in auth-store-*.js to compare the actual file content and validity.

Guidance

  • Review the maybeRestoreCredsFromBackup function in auth-store-*.js to identify the condition causing the false-positive warning.
  • Modify the detection logic to check for actual corruption by comparing the JSON content and schema of creds.json and creds.json.bak.
  • Verify that the creds.json file is valid JSON with the expected fields before emitting a warning.
  • Consider adding a check to ensure that the warning is only emitted when the files are not byte-identical.

Example

No code snippet is provided as the issue does not contain sufficient information about the implementation details of auth-store-*.js.

Notes

The provided information suggests that the issue is related to the detection logic in auth-store-*.js, but without the actual code, it is difficult to provide a precise solution.

Recommendation

Apply a workaround by modifying the maybeRestoreCredsFromBackup function to correctly detect corruption and only emit warnings when necessary, as the root cause of the issue appears to be a faulty detection logic.

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…
#serialization error#model compatibility#GPU setup#container setup#orchestration issue

Still need to ship something?

×6

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

Back to top recommendations

TRENDING