@whanext/core 0.19.5 → 0.19.8

package/CHANGELOG.md

@@ -1,5 +1,39 @@
 # Changelog
 
+## 0.19.8
+
+### Fixed
+- The Zapo mailbox (`messages`, `threads`, and `contacts`) is now persisted in the shared SQLite store and full history sync is enabled. This lets Zapo retain parent message secrets required to decrypt `secretEncryptedMessage` edit addons after restart/offline resume.
+- History sync now hydrates the trusted-contact/privacy-token state used by Zapo when preparing outgoing messages, including history-derived token metadata and NCT salt that can be required for `tctoken`/`cstoken` generation. Historical/bootstrap messages are still filtered by WhaNext and do not become live command events unless `processOfflineMessages` is explicitly enabled.
+- WhatsApp negative publish ACK `463` is normalized as `MESSAGE_REACHOUT_LOCKED` with `ackCode: 463` instead of surfacing as `UNKNOWN_ERROR`, allowing consumers to avoid retry/error-reply loops while the account is reach-out time-locked.
+
+### Compatibility
+- Public message/edit/delete event shapes are unchanged.
+- Existing shared multi-account stores are reused in place; the mailbox domains are created inside the same `state.sqlite` and remain isolated by `sessionId`.
+- The first connection after this update may perform a larger history sync because mailbox persistence is now enabled deliberately.
+
+## 0.19.7
+
+### Fixed
+- Zapo edit/revoke protocol mutations are now processed sequentially in arrival order. Back-to-back `MESSAGE_EDIT` -> `REVOKE` events can no longer race and make `messageDeleted.message` expose the pre-edit snapshot.
+- Protocol mutations discovered through the regular `message` event use the same ordered queue as native `message_protocol` events, preserving consistent AntiEdit/AntiDelete behavior across both Zapo delivery shapes.
+
+## 0.19.6
+
+### Fixed
+- Multi-account Zapo sessions now share a single SQLite store per sibling auth root and stay isolated by stable `sessionId`, matching Zapo's multi-session model.
+- Existing per-account `state.sqlite` sessions are migrated into the shared store on first use; removing one account auth directory resets only that account instead of affecting sibling sessions.
+- Zapo session/store handles are released on disconnect and terminal connection failures, preventing failed/restarted accounts from leaving stale SQLite resources behind.
+- Fatal disconnects such as `401`/`516` stop the reconnect loop and surface `AUTH_EXPIRED`; routine `515` reconnects immediately and `402` uses an extended backoff.
+- Passkey-gated linking now fails fast with `AUTH_PASSKEY_REQUIRED` when Zapo reports `auth_passkey_required` without a signer, instead of hanging until the login timeout.
+- `messageDeleted` and `messageEdited` can restore the previous message from a bounded persistent snapshot archive in `whanext-messages.sqlite` when the in-memory cache no longer contains it, including after cache eviction or a process restart.
+- Persistent mutation snapshots are isolated per `sessionId`, retained for up to 7 days, and capped at 20,000 messages per session to avoid unbounded storage growth.
+
+### Compatibility
+- Public `messageDeleted` / `messageEdited` event shapes are unchanged.
+- Existing single-account custom auth paths keep their previous per-directory SQLite layout.
+- `messages` remains disabled in the Zapo mailbox store; WhaNext persists only the compact message snapshot needed for edit/delete recovery in its own SQLite file.
+
 ## 0.19.5
 
 ### Fixed

package/MIGRATING_TO_ZAPO.md

@@ -33,12 +33,12 @@ npm install wa-store-migrate
 
 A conversão oficial lê `{ creds, keys }` do auth multifile, chama `migrate({ from: 'baileys', to: 'zapo', data })` e grava o resultado em um store Zapo novo. Consulte o guia oficial **Migrating from Baileys** do Zapo para usar o exemplo atualizado da versão que estiver instalada.
 
-No WhaNext, o destino deve ser o `state.sqlite` dentro do diretório `auth` da conta. O `sessionId` precisa ser estável:
+No WhaNext, o `sessionId` precisa ser estável:
 
 - `default` em `create()` quando `accountId` não é informado;
 - o `id` da conta em `createMulti()`.
 
-Converta cada conta separadamente quando usar multi-account.
+Em uma conta única com caminho `auth` customizado, o destino continua sendo `<auth>/state.sqlite`. Em multi-account, uma conversão antiga gravada em `<authRoot>/<id>/state.sqlite` é detectada e consolidada automaticamente no store compartilhado `<authRoot>/state.sqlite` na primeira inicialização da v0.19.6. Converta cada conta separadamente; o provider faz a consolidação sem misturar os `sessionId`s.
 
 ## Mensagens recebidas após reconexão
 

package/README.md

@@ -141,7 +141,7 @@ Nesse exemplo, `&open`, `!open`, `.abrir`, `&a` e `a` funcionam. `open` e `abrir
 
 ## Múltiplas contas
 
-Para manter duas, três ou mais contas de WhatsApp no mesmo processo, use `createMulti()`. Cada conta possui conexão, sessão, cache, reconexão e identidade próprios. A instância conjunta apenas coordena essas aplicações independentes.
+Para manter duas, três ou mais contas de WhatsApp no mesmo processo, use `createMulti()`. Cada conta possui conexão, `sessionId`, cache, reconexão e identidade próprios. No provider Zapo, contas irmãs compartilham o mesmo backend SQLite e permanecem isoladas pelo `sessionId`, evitando abrir um store concorrente por número.
 
 ```ts
 import {
@@ -179,7 +179,7 @@ await multi.login({
 });
 ```
 
-Quando `auth` não é informado na conta, o WhaNext cria automaticamente caminhos separados como `./sessions/principal`, `./sessions/secundaria` e `./sessions/terceira`. O mesmo diretório de sessão não pode ser usado por duas contas do provider padrão.
+Quando `auth` não é informado na conta, o WhaNext cria automaticamente caminhos separados como `./sessions/principal`, `./sessions/secundaria` e `./sessions/terceira`. Esses diretórios continuam identificando cada conta, enquanto o provider usa `./sessions/state.sqlite` como store compartilhado. O mesmo `id`/`sessionId` não deve ser usado por duas contas diferentes.
 
 Uma conta específica continua sendo um `WhaNextApp` completo:
 
@@ -197,7 +197,7 @@ if (principal?.isReady) {
 
 ## Mensagens apagadas
 
-Revogações recebidas pelo WhatsApp são expostas pelo evento `messageDeleted`. Quando a mensagem original ainda estiver no cache recente, o payload inclui `message`, que pode ser republicada ou usada para baixar a mídia pelas APIs existentes.
+Revogações recebidas pelo WhatsApp são expostas pelo evento `messageDeleted`. O provider mantém em `whanext-messages.sqlite` um snapshot compacto e persistente das mensagens recentes para recuperar `message` mesmo após expulsão do cache em memória ou reinício do processo. O snapshot é isolado por `sessionId`, retido por até 7 dias e limitado às 20.000 mensagens mais recentes por sessão.
 
 ```ts
 app.on('messageDeleted', async ({ message, deletedByMe }) => {
@@ -211,7 +211,7 @@ O evento também informa `deletedById` quando o WhatsApp fornece a identidade re
 
 ## Mensagens editadas
 
-Edições recebidas pelo WhatsApp são expostas pelo evento `messageEdited`. A partir da 0.17.1, o provider inclui suporte ao envelope criptografado `secretEncryptedMessage` usado atualmente pelo WhatsApp para edições. Quando a versão anterior ainda estiver no cache recente, o payload inclui `previous`; `message` contém a versão atual.
+Edições recebidas pelo WhatsApp são expostas pelo evento `messageEdited`. O provider inclui suporte ao envelope criptografado `secretEncryptedMessage` e mantém um snapshot compacto persistente para recuperar `previous` quando a versão anterior já saiu do cache em memória ou após reinício do processo. `message` contém a versão atual.
 
 ```ts
 app.on('messageEdited', async ({ previous, message, editedByMe }) => {
@@ -221,7 +221,7 @@ app.on('messageEdited', async ({ previous, message, editedByMe }) => {
 });
 ```
 
-Após cada edição, a nova versão substitui a anterior no cache recente. Assim, edições consecutivas da mesma mensagem sempre comparam a versão atual com a imediatamente anterior.
+Após cada edição, a nova versão substitui a anterior no cache e no snapshot persistente. Assim, edições consecutivas da mesma mensagem comparam a versão atual com a imediatamente anterior.
 
 ## Logging
 

package/dist/index.d.ts

@@ -610,7 +610,7 @@ declare class DeferredReply {
     delete(): Promise<void>;
 }
 
-type WhaNextErrorCode = 'AUTH_INVALID_PHONE' | 'AUTH_EXPIRED' | 'CONNECTION_CLOSED' | 'CONNECTION_FAILED' | 'GROUP_NOT_FOUND' | 'MEMBER_NOT_FOUND' | 'BOT_NOT_ADMIN' | 'MESSAGE_NOT_FOUND' | 'MEDIA_NOT_AVAILABLE' | 'MUTE_DISABLED' | 'STORAGE_ERROR' | 'ARGUMENT_MISSING' | 'ARGUMENT_INVALID' | 'COMMAND_NOT_ALLOWED' | 'COMMAND_COOLDOWN' | 'COMMAND_BUSY' | 'COMMAND_LOAD_FAILED' | 'PROVIDER_ERROR' | 'UNKNOWN_ERROR';
+type WhaNextErrorCode = 'AUTH_INVALID_PHONE' | 'AUTH_EXPIRED' | 'AUTH_PASSKEY_REQUIRED' | 'CONNECTION_CLOSED' | 'CONNECTION_FAILED' | 'GROUP_NOT_FOUND' | 'MEMBER_NOT_FOUND' | 'BOT_NOT_ADMIN' | 'MESSAGE_NOT_FOUND' | 'MEDIA_NOT_AVAILABLE' | 'MESSAGE_REACHOUT_LOCKED' | 'MUTE_DISABLED' | 'STORAGE_ERROR' | 'ARGUMENT_MISSING' | 'ARGUMENT_INVALID' | 'COMMAND_NOT_ALLOWED' | 'COMMAND_COOLDOWN' | 'COMMAND_BUSY' | 'COMMAND_LOAD_FAILED' | 'PROVIDER_ERROR' | 'UNKNOWN_ERROR';
 interface WhaNextErrorOptions {
     cause?: unknown;
     context?: Readonly<Record<string, unknown>>;