[Chatwoot Integration] WAHA attempts to send media before upload is complete on external storage (Wasabi S3)

[MrDandi79]

When integrating Chatwoot → WAHA (GoWS Plus) with external S3-compatible storage (Wasabi), WAHA attempts to send the media file before the upload is fully propagated or publicly accessible, resulting in a 404 error.

This leads to 2–3 failed attempts before the final retry succeeds.

---

💡 Steps to reproduce

1. Configure Chatwoot with external Active Storage (Wasabi S3):

   ACTIVE_STORAGE_SERVICE=s3_compatible
   STORAGE_ENDPOINT=https://s3.wasabisys.com
   

2. Connect WAHA Plus (GoWS) to Chatwoot via /api/sendFile.

3. Send a large attachment (e.g. 15–30 MB ZIP or XLSX).

4. Observe WAHA logs:

   • First attempt → AxiosError: 404

   • Second attempt → AxiosError: 404

   • Third attempt → success.

---

🧠 Expected behavior

WAHA should wait a few seconds before attempting to download and send the file, or allow configuration of a delay (backoff) between upload and media fetch.

---

⚙️ Current behavior

• WAHA calls fileToMedia() immediately after receiving the webhook from Chatwoot.

• At this point, the file URL (Active Storage redirect) still points to an object that isn't yet available in Wasabi.

• WAHA retries automatically but without a configurable delay, resulting in multiple unnecessary 404s.

---

🧩 Suggested solution

• Introduce an environment variable to delay the first attempt of media download, such as:

  WAHA_MEDIA_SEND_DELAY_MS=5000
  

  or

  WAHA_APPS_JOBS_BACKOFF=5000
  

• Alternatively, WAHA could check file availability (HTTP 200) before proceeding.

---

🧾 Environment

Component | Version -- | -- WAHA Version | 2025.9.7 (Plus, GoWS) Chatwoot | 3.x (Active Storage + Wasabi) Storage | Wasabi S3 (s3.wasabisys.com) OS | Ubuntu 24.04 (Easypanel VPS, 8GB RAM, 100GB SSD)

``

[devlikepro]

Could you explain (without gpt) what exactly happens?

1. Do you use S3 only for ChatWoot or WAHA as well?
2. Do you receive a message from WhatsApp or it's opposite - you send a file to ChatWoot?

[devlikepro]

before upload is complete on external storage

If it's ChatWoot who sends a file to S3 and S3 doesn't make it available immediately - it's no WAHA fault.

We have retries for this case, tho we need to add a way to disable retries messages and configure retries for different jobs 🤔 https://github.com/devlikeapro/waha/issues/1395

[MrDandi79]

Thanks for the clarification!

1. We use S3 (Wasabi) only for Chatwoot. WAHA also has S3 configured, but it doesn’t host or upload the same files — Chatwoot handles the upload to Wasabi through ActiveStorage.

2. The issue happens when Chatwoot sends a file to WhatsApp via WAHA.

Here’s the flow: Chatwoot → uploads the file to Wasabi → triggers the WAHA webhook → WAHA immediately tries to download the file → receives 404 because the file is not yet fully available on Wasabi.

After 2 or 3 retries, the file becomes available and the message is sent successfully.

It would be great if WAHA could include a small initial delay before the first sendMedia attempt — for example, a configurable delay of a few seconds.
That would prevent unnecessary 404 errors, reduce noisy retry messages, and improve the overall user experience, while still keeping the retry logic for reliability.

[MrDandi79]

This behavior does not occur when Chatwoot is configured with local storage — it only happens when external S3-compatible storage (Wasabi) is enabled. So the issue seems related to the short delay between Chatwoot finishing the upload and the file becoming publicly accessible on Wasabi.

[devlikepro]

Let's see how many and supporters needs the feature and prioritize it based on that.

Comment with "+1" if you need it!

[github-actions[bot]]

Portuguese

---

Vamos ver quantos [! [Patrono: Plus] (https://img.shields.io/badge/patron-plus-a0e6ba)] (https://waha.devlike.pro/docs/how--wplus-version/#tiers) e [! [patrono: pro] (https://img.shields.io/badge/patron-pro-188a42)] (https://waha.devlike.pro/docs/how-to/plus-version/#tiers) Os suporações precisam do recurso e priorizá-lo baseados em.

** Comentário ** com "+1" se você precisar!

[MrDandi79]

+1

[rafwell]

+1

[guilombardi91]

+1

[alessandrovolpin]

+1

[devlikepro]

2025.10.2 - No retries/success messages - temp fix - #1395