Problem

The three auth-state providers read the persisted app-state sync key with proto.Message.AppStateSyncKeyData.create(value):

• src/utils/use-multi-file-auth-state-prisma.ts:185
• src/utils/use-multi-file-auth-state-redis-db.ts:64
• src/utils/use-multi-file-auth-state-provider-files.ts:119

create() is a bare constructor: it copies own properties and performs no type coercion. fromObject() is the one that converts, and for bytes fields it base64-decodes a string into a Uint8Array. Baileys' own reference implementation uses fromObject() for exactly this reason (Utils/use-multi-file-auth-state.ts).

The value is stored as base64 text because protobufjs Message.toJSON() uses util.toJSONOptions with bytes: String, so the Uint8Array is already a string by the time BufferJSON.replacer runs. Reading it back with create() leaves it a string, and the round trip is asymmetric.

Consequence

hkdf() receives a string and evaluates new Uint8Array("7ae+...") → ToIndex(NaN) → length 0. Every mutation key is derived from empty key material:

Invalid patch mac
failed to sync state from version, removing and trying from scratch
error:1C800064:Provider routines::bad decrypt
resyncing regular from v0        <- loops forever

It looks fine for the first few minutes after pairing because makeCacheableSignalKeyStore serves the original Buffer-bearing object from its NodeCache (SIGNAL_STORE, 5 min TTL). After expiry the cold read returns the corrupt string — and writes it back into the cache, so it never recovers on its own.

The whole regular collection is affected. The way it usually surfaces: chat labels applied on the phone stop reaching the webhook, labels.association fires during pairing and never again.

A useful diagnostic: a healthy instance persists app-state-sync-version-* for all five collections; a broken one only ever has critical_block.

Fix

create( → fromObject( at the three call sites. grep -rn AppStateSyncKeyData src/ returns exactly those three hits.

Regression origin

Introduced in 8830f47 (bump to v2.3.3). v2.3.2 is clean; v2.3.3 through v2.3.7, main and develop all carry it. The three files are byte-identical across those refs, so this patch applies unchanged to all of them.

Verification

Reproduced and fixed on a real 2.3.7 instance (Baileys 7.0.0-rc.9), with both the Redis and the file storage backends — they fail identically, which is what pointed above the storage layer in the first place.

Empirically, on the same instance:

create()     -> keyData is a 44-char String
fromObject() -> keyData is the correct 32-byte Buffer

After the change, the instance resynced regular from v0 to v19 with zero decrypt errors and label events resumed immediately. Keys already persisted in the broken format are recovered as-is — no re-pairing is required, which matters for anyone who has been running a broken instance for a while.

Note

This is the same fix as #2593, which was closed for targeting main. This one targets develop per CONTRIBUTING.

🤖 Generated with Claude Code

Summary by Sourcery

Bug Fixes:

• Fix app-state sync key deserialization by using the protobuf fromObject API so persisted keys are loaded as binary data rather than base64 strings, preventing broken HKDF derivation and state sync failures across Prisma, file, and Redis auth-state backends.