Reviewer's Guide

Refactor persistence logic to conditionally perform database operations based on configurable SAVE_DATA flags, ensuring correct behavior when messages are not stored.

Flow diagram for conditional message persistence logic

flowchart TD
    A[Receive message update] --> B{SAVE_DATA.HISTORIC or SAVE_DATA.NEW_MESSAGE?}
    B -- Yes --> C[Find message in DB]
    C -- Found --> D[Set messageId]
    C -- Not found --> E[Skip setting messageId]
    B -- No --> F[Skip DB lookup]

Flow diagram for conditional message update persistence

flowchart TD
    A[Message update event] --> B{SAVE_DATA.MESSAGE_UPDATE?}
    B -- Yes --> C[Create messageUpdate in DB]
    B -- No --> D[Skip DB operation]

Flow diagram for conditional message edit validation

flowchart TD
    A[Edit message request] --> B{SAVE_DATA.NEW_MESSAGE?}
    B -- Yes --> C[Validate oldMessage exists and is valid]
    B -- No --> D[Skip validation]

File-Level Changes

Possibly linked issues

• #0: The PR modifies the Baileys service to handle non-persisted messages, preventing database errors that cause webhook failures.
• Problemas ao enviar mídias para o Celular usando o Typebot ou Postman #123: The PR ensures the API functions correctly when messages are not persisted, which is likely the underlying cause of messages not being sent.

@DavidsonGomes as alterações são referentes ao uso da Evolution sem salvar as mensagens em banco de dados.
As principais alterações são devido aos métodos fazerem busca do banco de dados para validar as mensagens, porém no caso quando não existe informações no banco ocorria erro ao utilizar a API.

1. Referente a alteração dentro do "message.update" onde foi adicionada a verificação do configDatabaseData.HISTORIC ou configDatabaseData.NEW_MESSAGE é devido que não era enviado os eventos de webhook quando o ACK da mensagem era atualizado.

2. Referente a alteração do "deleteMessage" é que ao utilizar a rota da API para deletar uma mensagem ocorria erro no deleteMany pois usava o message.id, porem message sempre é undefined.

3. Referente ao método "formatUpdateMessage", o this.getMessage nunca encontrava nada e sempre retornava null, fazendo com que as mensagens não fosse editadas.

4. Referente ao "updateMessage", foi ajustado para que as validações e chamadas do prisma só sejam feitas quando os dados estão persistidos em banco, caso contrário acusa falso erro ou update em registro inexistente.

Lembrando que essas alterações são referentes a quando as opções na env de SAVE_NEW_MESSAGE está definida como false, no nosso caso, usamos a EvolutionAPI apenas como intermediário para troca de mensagens, com envio e recebimento e re-envio dos eventos via webhook/socket, não utilizamos as tabelas da Evolution para salvar as mensagens.