Las fotos reciben reacción igual que el texto: el bug de iOS ya no aplica

Qué pasaba

Cuando Gabriel mandaba una foto (imageMessage o videoMessage) en un grupo de WhatsApp, el asistente

no ponía ni el ⚡ de acuse ni el ✔️ de completado. Las fotos se procesaban igual que los textos —se

descargaban, se les hacía OCR, se mandaban al modelo— pero el feedback visual de las reacciones no

aparecía.

Por qué

En bridge.service.ts línea 274 había una exclusión explícita:

stored.type !== 'imageMessage' && stored.type !== 'videoMessage'

Un comentario decía que era para «evitar el bug de iOS donde WhatsApp no correlaciona la reacción y

muestra un globo falso de Esperando el mensaje». Ese bug de Baileys ocurría cuando la reacción no

incluía el participant correcto en la key del mensaje en grupos.

Por qué ya no aplica

sendReaction en client.ts ya tiene un pipeline de resolución del participant con tres fallbacks:

1. Lo busca en pending_reactions de SQLite
2. Lo busca en rawJson.key.participant del mensaje guardado
3. Fallback hardcodeado para los grupos directos de Gabriel

Con el participant bien resuelto, Baileys 6.7.18 envía la reacción correlacionada al mensaje

original y WhatsApp no muestra el globo fantasma.

Además, handleSubscriptionsNotification (línea 1712) ya mandaba reacciones a imágenes con 👀 sin

problema, lo que confirma que el bug no estaba vigente.

Qué se cambió

Se quitó la exclusión de imageMessage / videoMessage y se diferenció el emoji: 👀 para fotos y

videos (indica que se vio la imagen), ⚡ para texto y audios. Así queda consistente con

subscriptions y las fotos reciben tanto el acuse inmediato como el cierre.

Riesgo

Bajo. El mismo código sin la exclusión ya corría para subscriptions sin reportes de problemas.

🔗 Conexiones Neuronales

• Eje: elevar-conciencia|Elevar Conciencia · Dirección Estratégica
• Eje: asistente-gaby
• Eje: desarrollo-de-capacidades|Desarrollo de Capacidades & Empoderamiento

Decisiones/fotos-reciben-reaccion-bug-ios-no-aplica