Problem with big files (200mb) in API inbox #10470
Comments
|
@BrOrlandi Interesting! I don't think we support PSD files. How did you upload this to Chatwoot? |
|
I think you are using whatsapp API inbox using official API or you are using any third party app to connect to chatwoot using API? |
|
Yes @shivamkb17, I'm using a third-party app to connect to Chatwoot via API, and the file was sent by a customer via WhatsApp. |
|
@BrOrlandi It’s interesting to note that the WhatsApp Cloud API documentation states the maximum file size for any format is 100MB.
We have not handled the case where the attachment is more than 100mb.
At the moment, no. We will consider this in the upcoming updates.
This is possible, and the likely reason is that your machine is running out of memory. How much storage space is left on the device? |
Just to confirm. Are you using unofficial API? Or are you using Cloud API/self-hosted API via a BSP? |
pranavrajs
added
investigation
|
@pranavrajs Yes, I'm using an unofficial WhatsApp API. I'm using the Evolution API, a great project that connects Whatsapp directly to Chatwoot: https://github.com/EvolutionAPI/evolution-api/. Besides the cloud API limits to 100mb on upload, the normal API seems to have no limit and it's possible to send a file of 200mb or even more. My device currently has 30 GB in available space, so it should not be an issue. |
|
ok, I understood the issue, This issue is due to evolution send file to chatwoot using webhook in base64 formate, for this larger media file, the base64 code is too big. so chatwoot server is crashing. |
|
I am here responding, due to I faced similar problem while testing the unofficial API integration. but I am using wppconnect that time. |
|
Great find @shivamkb17, so I think it needs to be fixed on both Chatwoot and Evolution. On Chatwoot, it's possible to avoid processing the base64 when it's too big? Maybe it's important to have a notification in the chat, so the Agent can be notified the user tried to send a big file that can't be processed. On Evolution, it needs to send big files through media file instead of base64. I will talk to the Evolution team about it so they may change to use the media file instead of base64. |
|
@BrOrlandi @shivamkb17 We'd be happy to accept a PR to limit the document size on the PR if you are interested. |
|
@pranavrajs Sure I will take a look into it. What can I do. |
Describe the bug
I’m using an API inbox integration connected to our company's WhatsApp Business account. Couple days ago, a client sent a large 200MB Photoshop (PSD) file, which caused our server to crash completely—I had to restart the machine to bring everything back online. I verified this was the issue because a team member attempted to send the same file again, and it caused another crash.
We're hosted on Oracle Cloud with a machine of 1 CPUs and 4GB of RAM, which usually handles Chatwoot v3.12 without any issues.
My question is: Can Chatwoot be prevented from downloading or processing files above a certain size limit? Currently, file uploads to S3 are enabled for Chatwoot, and it seems that Chatwoot might be downloading the file through the API integration before uploading to S3, causing the crash. As it stands, any client sending a large file, such as 200MB, is enough to make my Chatwoot server go down. I'm using S3 compatible Object Storage from Oracle Cloud also.
To Reproduce
Environment:
1 CPU and 4GB of RAM
Chatwoot v3.12
Set up an API inbox.
Send a message from the customer to the inbox with a file of at least 200mb.
The server should crash trying to download and process this file.
Expected behavior
Chatwoot shoud not crash.
Environment
app.chatwoot.com
Cloud Provider
Other [please specify in the description]
Platform
Browser
Operating system
Linux
Browser and version
Chrome (doesn't matter the problem happens on the server)
Docker (if applicable)
docker version
Client: Docker Engine - Community
Version: 27.3.1
API version: 1.47
Go version: go1.22.7
Git commit: ce12230
Built: Fri Sep 20 11:40:59 2024
OS/Arch: linux/amd64
Context: default
Server: Docker Engine - Community
Engine:
Version: 27.3.1
API version: 1.47 (minimum version 1.24)
Go version: go1.22.7
Git commit: 41ca978
Built: Fri Sep 20 11:40:59 2024
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.7.22
GitCommit: 7f7fdf5fed64eb6a7caf99b3e12efcf9d60e311c
runc:
Version: 1.1.14
GitCommit: v1.1.14-0-g2c9f560
docker-init:
Version: 0.19.0
GitCommit: de40ad0
Client: Docker Engine - Community
Version: 27.3.1
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.17.1
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.29.7
Path: /usr/libexec/docker/cli-plugins/docker-compose
Server:
Containers: 8
Running: 8
Paused: 0
Stopped: 0
Images: 7
Server Version: 27.3.1
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 7f7fdf5fed64eb6a7caf99b3e12efcf9d60e311c
runc version: v1.1.14-0-g2c9f560
init version: de40ad0
Security Options:
apparmor
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.8.0-1014-oracle
Operating System: Ubuntu 24.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.819GiB
Name: chatwoot
ID: 52b6b1d7-d6fc-437f-8f58-1cb2cdae1956
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled
Additional context
This issue was discussed before on Discord Community: https://discord.com/channels/647412545203994635/1302399701915533312
The text was updated successfully, but these errors were encountered: