Repository navigation
files_upload_v2: files over 1 GB fail with an opaque "EOF occurred in violation of protocol" SSL error instead of a size error #1993
Description
Reproducible in:
The Slack SDK version
slack_bolt==1.30.0
slack_sdk==3.44.1
Python runtime version
Python 3.11.2 (OpenSSL 3.0.17 1 Jul 2025)
OS info
Debian GNU/Linux 12.11
1 SMP PREEMPT_DYNAMIC Debian 6.1.140-1 (2025-05-22)
Steps to reproduce:
- Create a file larger than Slack's 1 GB per-file limit (in our case a ~1.9 GB zip of CSV data).
- Upload it with
files_upload_v2using a bot token withfiles:write:
from slack_sdk import WebClient
client = WebClient(token="xoxb-...", timeout=1200)
with open("big.zip", "rb") as f:
content = f.read() # ~1.9 GB
client.files_upload_v2(
channel="C0123456789",
filename="big.zip",
content=content,
initial_comment="results",
)- Observe the exception raised during the upload step (the POST to the
upload_url)
Additionally, calling the first step directly shows that the size is never
client.files_getUploadURLExternal(filename="probe.zip", length=1_903_583_688) # ok: true, returns upload_url
client.files_getUploadURLExternal(filename="probe.zip", length=5_000_000_00) # ok: true, returns upload_urlExpected result:
A clear, actionable error saying the file exceeds the maximum upload size, for example:
files.getUploadURLExternalreturning an error such asfile_too_largewhenlengthexceeds the limit, and/orfiles_upload_v2checking the content length on the client side before uRequestError/SlackApiError` that names the limit.
Actual result:
files.getUploadURLExternalreturnsok: trueand anupload_urleven- The POST of the file bytes to
https://files.slack.com/upload/v1/...then fails partway through. The connection is closed without an HTTP error response, andurllibraises:
urllib.error.URLError: <urlopen error EOF occurred in violation of protocol (_ssl.c:2393)>
- Depending on timing we also saw
<urlopen error The write operation timed out>with the default 30 s timeout. Raisingtimeoutto 1200 s did not help; the SSL EOF error continued. - Uploads of 1 MB, 3 MB and 8 MB from the same host through the same upload URL flow succeed in about 1–2 seconds, and files of a few hundred MB upload fine. So this is not a general network problem; it only happens once the file is over the limit.
Because the error looks like a TLS or network failure, it took a long time se was the file size. We now check the size ourselves before callingfiles_upload_v2, but the SDK (or the API) reporting the limit directly would save other users the same debugging.
Activity
hello-ashleyintech commentedon Oct 21, 2026
Hey @chu-siang, thanks so much for the thorough report — and sorry you had to go through that debugging rabbit hole! This is definitely a real bug and we want to get it sorted.
Here's what's going on: when
files_upload_v2runs, it first calls Slack'sfiles.getUploadURLExternalAPI to get an upload slot. The tricky part is that Slack's API happily returnsok: trueand a valid upload URL even when the file is over their 1 GB limit — no warning at all. Then when the SDK actually tries to send the bytes, Slack silently closes the connection partway through. Since the connection drop happens at the network/TLS layer rather than as a normal HTTP error, Python ends up surfacing that confusingEOF occurred in violation of protocolSSL error instead of anything useful like "hey, your file is too big." Totally understandable that it took a while to track down!In the meantime, here's a workaround:
Check the file size before calling
files_upload_v2:One small tip: pass a file path (
file=file_path) instead of reading the whole file into memory first — for large files this saves you from loading gigabytes into RAM only to hit the error anyway!What we're planning to fix:
The SDK already computes the file's byte length internally before making any API calls, so we can slot in a size check there that raises a clear, human-readable
SlackRequestErrornaming the 1 GB limit. That way you'd get an actionable error right away instead of a mysterious SSL failure after waiting through a partial upload.Thanks again for the detailed repro steps — they're really helpful!