[BUG] messages not read / messages.upsert not working after panel auto restart

[aldiidev]

Describe the bug
Sometimes when the panel auto restarts, the bot cannot read incoming messages, and must delete the session and reconnect.

Environment (please complete the following information):

• Is this on a server? yes
• Do you have multiple clients on the same IP? yes
• Are you using a proxy? no

Additional context
client = makeWASocket({
version,
auth: state,
logger: pino({ level: 'silent' }),
browser: Browsers.windows('Chrome'),

        syncFullHistory: false,
        shouldSyncHistoryMessage: () => false,
        markOnlineOnConnect: false,

        shouldIgnoreJid: (jid) => jid.includes('broadcast') || jid.endsWith('@status'),
    });

im using V7 RC-8
any suggestions?

[eric-t-a]

up

[joe-arms]

up version to github latest commit [https://github.com//pull/2264]

[MichelleBot]

up version to github latest commit [https://github.com//pull/2264]

still the same

[makanSukros]

Still same problem here

[eric-t-a]

up version to github latest commit [https://github.com//pull/2264]

worked for me!
I updated with npm i @whiskeysockets/baileys@WhiskeySockets/Baileys#master

[mission-sun]

up version to github latest commit [https://github.com//pull/2264]

How to use latest commit，the source code downloaded is not packaged, and the path cannot be found.

[eric-t-a]

up version to github latest commit [https://github.com//pull/2264]

worked for me! I updated with npm i @whiskeysockets/baileys@WhiskeySockets/Baileys#master

nevermind. Stopped working again

[alessandropcostabr]

What stands out to me here is that the issue may be less “Baileys fully disconnected” and more session looks alive after restart, but the inbound event pipeline is functionally dead.

We ran into similar operational behavior in production integrations: after a restart, the socket can appear connected enough to avoid immediate failure, but messages.upsert never resumes in a healthy way. Deleting the session + re-pairing then appears to “fix it”, but that usually just resets the state completely instead of explaining the root cause.

So I would frame this as a possible zombie session after restart.

What I would instrument before concluding this is a pure library bug:

1. connection.update
2. creds.update
3. timestamp of last successful messages.upsert
4. timestamp of last successful send
5. whether the socket is “connected” but inbound has been silent for much longer than expected

The important distinction is:

• transport connected != inbound pipeline healthy

A useful operational rule is:

• if the socket reports connected/open
• but you have known traffic and no messages.upsert for an abnormal interval after restart
• treat the session as degraded, not healthy

That lets you detect the bad state explicitly instead of waiting until operators notice missing messages.

I would also avoid treating “delete session and reconnect” as a real fix. It is a strong signal that some restart/reload path is leaving auth/store/socket state inconsistent.

Practical troubleshooting checklist for this issue:

1. After restart, log connection.update transitions until steady state.
2. Log whether creds.update keeps happening normally.
3. Record lastInboundAt whenever messages.upsert fires.
4. If the socket is open but lastInboundAt is stale far beyond expected traffic, flag the session as zombie/degraded.
5. Compare behavior between:
   • fresh QR pair
   • restart with persisted auth
6. If only the persisted-auth restart path fails, the bug is likely in rehydration / state recovery rather than basic connectivity.

The current comments in this thread (“update to latest commit”, “worked”, “stopped again”) also support that interpretation: this does not look like a clean deterministic fix. It looks like an intermittent state-recovery problem.

So my take is:

• this issue is still very plausible,
• but it should be debugged as post-restart session health / zombie state, not only as “messages.upsert randomly broken”.

[kobie3717]

This is the same class of issue as #2331 — the session looks alive after restart but inbound events stop firing. A few of my open PRs address the underlying causes:

• fix: connection stability overhaul — prevent disconnects, memory leaks, and zombie sockets #2405 — Connection stability overhaul: Proper cleanup on disconnect prevents zombie socket state that persists across restarts
• fix: resolve Bad MAC, No Session, Invalid PreKey errors (#1769) #2372 — Bad MAC / Session fix: Session/prekey corruption after restart can silently break decryption — connection stays open but messages can't be processed

Running multiple clients on the same IP compounds this — each reconnect can invalidate the previous session's keys. If you're seeing this consistently after restarts, try deleting the auth state and re-pairing as a temporary workaround.