Labels created in WhatsApp Business are never synced to the session — findLabels only returns labels from first pairing (Baileys 7.0.0-rc.9) #2576

Environment

• Evolution API: v2.3.7 (self-hosted, Docker)
• Engine: Baileys (whatsapp-web) — baileys@7.0.0-rc.9
• DB: PostgreSQL, DATABASE_SAVE_DATA_LABELS=true
• Instance state: open / healthy at all times during the test

Description

Labels created in the WhatsApp Business app — including on a linked device such as WhatsApp Web Business — are never reflected in the Evolution session. GET /label/findLabels/{instance} keeps returning only a small, stale set of labels that were captured at the very first pairing of the instance. Newly-created Business labels never appear, in the API response or in the Label table. Because of this, label automation via POST /label/handleLabel/{instance} is impossible: the new labels never receive an id in Evolution to reference.

Steps to reproduce

1. Pair an instance with the Baileys engine; confirm connectionState = open.
2. In WhatsApp Business (primary phone or a linked device / WhatsApp Web Business), create one or more new labels.
3. GET /label/findLabels/{instance}.

Expected

The newly-created labels are returned (and stored in the Label table), so they can be used with handleLabel.

Actual

Only the labels that existed at the first pairing are returned. New labels never appear. The Label rows have createdAt == updatedAt frozen at the initial pairing timestamp and are never refreshed.

Verified — it is not a config or transient issue

• DATABASE_SAVE_DATA_LABELS=true.
• Persists across POST /instance/restart/{instance} (reconnects to open, still only the stale labels).
• Persists across full QR re-pairs performed on different days: the Label rows kept their original createdAt/updatedAt, i.e. re-pairing did not re-sync labels. (In our case the labels are frozen ~12 days before the most recent re-pair.)
• No label-create endpoint exists (POST /label/create… → 404), so creating in the app is the only path — and that path never propagates to the session.

Likely root cause

Baileys app-state label mutations (labelEditAction, in the regular app-state collection) are not being consumed on reconnect. Baileys does an incremental app-state sync on reconnect (only mutations after its stored version), and label mutations — especially those created on a linked device — are not applied. This appears related to known Baileys 7.x app-state / sync-on-connect problems:

• [BUG] Sync events not firing consistently while scanning QR WhiskeySockets/Baileys#1620 — sync event (type 0, contacts/app-state) does not fire reliably on QR scan.
• The syncFullHistory=false app-state regression in Baileys 7.x (fixed in source but not yet released to npm; latest published is still 7.0.0-rc.9, which Evolution bundles).

Suggested fixes / asks

1. A way to force a full app-state resync of the regular (labels) collection without deleting the instance — e.g. an endpoint, or call resyncAppState(['regular']) on (re)connect / on demand.
2. And/or bump the bundled Baileys to a build that includes the app-state sync fix once it is published.
3. And/or expose a label create endpoint so labels can be provisioned via API instead of depending on linked-device app-state sync.

Evidence sample (sanitized)

GET /label/findLabels/{instance}  ->  only 3 stale entries, e.g.:
  { name: "Favoritos", ... }, { name: "Grupos", ... }, { name: "No leidos", ... }
Label table: createdAt == updatedAt == <first-pairing timestamp>, never updated,
while ~12 newly-created Business labels exist in the WhatsApp account and are visible on every other device.