2

Dois cuidados nesse esquema. O caminho sqlite:buffer_webhooks.sqlite é relativo, então o arquivo provavelmente fica na mesma pasta pública do webhook.php, e aí quem acertar a URL baixa o banco com todas as mensagens do WhatsApp. Vale mover pra fora da raiz do site ou bloquear .sqlite no servidor.

O outro é a sobreposição: se o fluxo do n8n demorar mais de 1 minuto com os 50, o próximo disparo pega os mesmos pendentes e o cliente recebe resposta dobrada. Eu marcaria como processando antes de começar (dá pra fazer com UPDATE ... RETURNING) e ligaria o WAL com um busy_timeout no PHP, porque com muita requisição chegando junto o SQLite começa a devolver database is locked.

Carregando publicação patrocinada...
1

Cara, que comentário valioso, muito obrigado! Os dois pontos são falhas reais e eu tinha deixado passar.

O do caminho relativo é sério, já que qualquer um poderia baixar o .sqlite com as conversas. Vou mover o arquivo pra fora da raiz pública.

A sobreposição também faz todo sentido: se o lote passar de 1 minuto, o cliente recebe resposta dobrada. Vou marcar como “processando” com UPDATE ... RETURNING antes de começar e ativar WAL + busy_timeout no PHP pra evitar o “database is locked” nos picos.

É por isso que vale compartilhar, a comunidade acha o que a gente não vê. Vou atualizar o post com essas correções e te dar o crédito!

1

valeu, Edson, e vi que já virou versão em Go. só um detalhe na hora de mover: com o WAL ligado o SQLite cria os arquivos -wal e -shm do lado do .sqlite, então a pasta toda precisa sair da raiz pública, não só o arquivo do banco.