Skip to content

Un timeout del catálogo no es un catálogo vacío: getCatalog y productDelete responden 504 cuando WhatsApp no contesta (Baileys #2717) - #5

Merged
LuanFuentes merged 2 commits into
mainfrom
catalogo-timeout-no-es-vacio
Sep 18, 2026
Merged

LuanFuentes merged 2 commits into
mainfrom
catalogo-timeout-no-es-vacio

Conversation

@LuanFuentes

Copy link
Copy Markdown
Owner

Qué pasaba

WhatsApp dejó de contestar la familia w:biz:catalog por QR — leer catálogo y colecciones, crear/editar/borrar productos — para todas las líneas (Dulti, Vitalex, Smart Home, medido el 18-sep: 62 s cada una). Es Baileys evolution-foundation#2717, abierto desde julio y sin arreglo.

Y Baileys 7 rc14 lo esconde: waitForMessage atrapa el «Timed Out» y devuelve undefined; parseCatalogNode(undefined) da products: []. Así getCatalog respondía «0 productos» y productDelete «deleted: 0», exactamente a los 60 s. Quien lo lee concluye «el teléfono no tiene catálogo» (Smarty lo concluyó, y el founder también).

Qué cambia

  • src/api/extensions/business/catalogo.puro.ts (nuevo, sin Baileys): elIqDelCatalogo (mismo nodo que Baileys getCatalog), elCatalogoDelNodo (lee el producto entero, con retailer_id, imagen original, oculto, estado y cursor), elJidSinDispositivo, elIqDeBorrarProductos, losBorradosDelNodo.
  • business.service.ts: getCatalog y productDelete mandan el IQ por client.query — un resultado undefined es 504 «WhatsApp no contestó la consulta del catálogo (w:biz:catalog expira a los 60 s; Baileys fix(baileys): recreate messageSubject when it is stopped, not only closed evolution-foundation/evolution-api#2717)», nunca un catálogo vacío. Misma forma de respuesta que upstream (wuid, numberExists, isBusiness, catalogLength, catalog) más retailerId por producto. elSocket compartido con getOrderDetails.
  • business.router.ts: POST /business/getCatalog y POST /business/productDelete pisan a los de upstream/capacidades (este router se monta antes en index.router). productCreate/productUpdate siguen en capacidades: ante el timeout ya tiran (parsean undefined) y salen como 502.

Evidencia

  • npm run test:fork 18/18 (5 nuevas: el IQ, la lectura del nodo con retailer_id/imagen/cursor, respuesta rara, jid sin dispositivo, borrado).
  • tsc --noEmit ✅ · eslint ✅ en src/api/extensions.
  • Después del deploy: POST /business/getCatalog/dulti-dulti-protein-5415c6 debe responder 504 con ese mensaje (hoy: 200 «0 productos»).

🤖 Generated with Claude Code

LuanFuentes and others added 2 commits September 18, 2026 13:08
…Delete responden 504 cuando WhatsApp no contesta

WhatsApp dejó de contestar la familia w:biz:catalog por QR (Baileys evolution-foundation#2717, abierto desde
julio). Baileys rc14 atrapa el «Timed Out» en waitForMessage y devuelve undefined, y
parseCatalogNode(undefined) da products: [] — getCatalog respondía «0 productos» a los 60 s
exactos para todas las líneas, y productDelete «deleted: 0». Acá el IQ va por client.query
(catalogo.puro.ts, mismo nodo que Baileys, leído entero con retailer_id) y un resultado
undefined es 504 «WhatsApp no contestó». Las rutas pisan a las de upstream: el router de
extensiones se monta antes. 5 pruebas puras.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@LuanFuentes
LuanFuentes merged commit 3d38dbd into main Sep 18, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant