`/session/status` returns empty `jid` after `PairSuccess` (userinfo cache not refreshed) — DB has the correct jid

[LeXaMeN]

Summary

After a successful QR pairing, GET /session/status returns "jid": "" even though connected: true and loggedIn: true, and even though the users.jid column in the database holds the correct JID. The JID is written to the DB on PairSuccess, but the in-memory userinfo cache that /session/status reads from is not refreshed, so the endpoint keeps returning an empty jid until the process is restarted (on restart the cache is loaded from the DB and the value appears again).

This breaks integrations that rely on /session/status.jid to learn the connected phone number right after pairing.

Environment

• wuzapi commit: 70642149a0e8a81d49caa640f557217e03e09729 (branch main)
• whatsmeow: v0.0.0-20260721154117-8b4a8ba0d318 (latest at build time)
• Build: CGO_ENABLED=0, GOOS=linux, DB backend: PostgreSQL
• Go: 1.25.x

Steps to reproduce

1. Create a user via the admin API and connect it (/session/connect).
2. Scan the QR code with a phone to pair. PairSuccess fires and is logged with the correct JID.
3. Immediately call GET /session/status with the user token.

Expected

/session/status returns the paired JID:

{ "connected": true, "loggedIn": true, "jid": "7989XXXXXXX:65@s.whatsapp.net", ... }

Actual

jid is empty although the session is logged in:

{ "connected": true, "loggedIn": true, "jid": "", ... }

Evidence

Logs at pairing time — JID is correctly computed and written to the DB:

INFO  QR Pair Success  ID=7989XXXXXXX:65@s.whatsapp.net Platform=android token=<token> userid=<userid>
DEBUG User info updated  field=Jid value=7989XXXXXXX:65@s.whatsapp.net
INFO  User information set  jid=7989XXXXXXX:65@s.whatsapp.net token=<token> userid=<userid>

A couple of seconds later, /session/status reads from the cache and gets nothing:

INFO  User info name from Cache  name=
INFO  User info values  ... Jid= Name=<user> ...
INF   Got API Request  url=/session/status status=200 ...

Database confirms the JID is stored (so it is purely a read/cache issue, not a write issue):

SELECT id, jid, name, connected FROM users;
-- <userid> | 7989XXXXXXX:65@s.whatsapp.net | <user> | 1

Notes / likely cause

It looks like PairSuccess persists the JID to the DB but does not update the cached userinfo entry that the /session/status handler reads (userInfo.Get("Jid")). A process restart repopulates the cache from the DB, which is why the value reappears only after a restart.

Possible fixes:

• Refresh/invalidate the userinfo cache entry when the JID is updated (on PairSuccess/Connected), or
• Have /session/status read the JID from the DB (or fall back to the DB when the cached value is empty while loggedIn: true).

Also relevant context: this build runs with a recent whatsmeow that performs the LID migration (the PairSuccess payload now includes both ID (@s.whatsapp.net) and LID (@lid)); the phone JID is still available in the DB, only the /session/status cache read is empty.

[LeXaMeN]

Additional observation from the same build (possibly related, since both surfaced after moving to the LID-migration whatsmeow):

During HistorySync processing, the gateway logs a large number (hundreds) of:

WARN Cannot determine sender JID, skipping message messageID=3EB0XXXXXXXXXXXXXXXX role=wuzapi

They appear right around the history-sync save step, e.g.:

INFO Saved HistorySync messages to message_history savedCount=64 userID=<userid>
WARN Cannot determine sender JID, skipping message messageID=3ACD27F16DB47CB1A66A
WARN Cannot determine sender JID, skipping message messageID=3EB0E18D72689690421AD5
... (hundreds more)

Context / what we observed:

• This happens while syncing historical messages right after pairing (the PairSuccess payload now carries both ID = ...@s.whatsapp.net and LID = ...@lid, and Props include isChatDbLidMigrated: true, isSyncdPureLidSession: true).
• It looks like some historical messages only have a LID-based sender that can't be resolved to a phone JID, so they are skipped.
• Live/incoming messages after connect are not affected — those arrive with a normal Info.Chat / Info.Sender = ...@s.whatsapp.net.

So this is not blocking for us, but the volume of WARN lines is very noisy, and some historical messages are silently dropped. It may be worth either:

• lowering the log level for this case (or aggregating it into a single summary line with a skipped-count), and/or
• falling back to the LID (or the phone↔LID mapping already present in the HistorySync payload, phoneNumberToLidMappings) to resolve the sender instead of skipping.

Environment is the same as in the issue above (wuzapi main @ 70642149a0e8a81d49caa640f557217e03e09729, whatsmeow v0.0.0-20260721154117-8b4a8ba0d318, PostgreSQL, CGO_ENABLED=0).

[RuanAyram]

up

[AntonKun]

up

[AntonKun]

@asternic
Please check my PR it fixes the issue with JID:
#333