What causes "Request Entity Too Large" in argoproj/argo-workflows?

Check the file size before upload and reject/truncate oversized files client-side

Request Entity Too Large

Error message

Request Entity Too Large

What it means

The request body size is capped by ARGO_SERVER_MAX_ARTIFACT_UPLOAD_BYTES (default 1GiB) via http.MaxBytesReader. If r.ParseMultipartForm fails specifically with *http.MaxBytesError, the handler responds 413 'Request Entity Too Large'. Other parse failures fall through to a 400.

Source

Thrown at server/artifacts/artifact_server.go:165

	if err != nil {
		a.serverInternalError(ctx, err, w)
		return
	}
	r.Body = http.MaxBytesReader(w, r.Body, int64(maxUploadBytes))

	// mime/multipart.ReadForm already removes temp files on parse error, but
	// registering cleanup here makes the handler's correctness independent of
	// that stdlib internal — any future error return still frees temp files.
	defer func() {
		if r.MultipartForm != nil {
			_ = r.MultipartForm.RemoveAll()
		}
	}()

	// Parse multipart form (max 32MB in memory, rest on disk)
	if parseErr := r.ParseMultipartForm(32 << 20); parseErr != nil {
		if _, ok := errors.AsType[*http.MaxBytesError](parseErr); ok {
			http.Error(w, http.StatusText(http.StatusRequestEntityTooLarge), http.StatusRequestEntityTooLarge)
			return
		}
		http.Error(w, "Failed to parse multipart form: "+parseErr.Error(), http.StatusBadRequest)
		return
	}

	file, header, err := r.FormFile("file")
	if err != nil {
		http.Error(w, "Failed to get file from form: "+err.Error(), http.StatusBadRequest)
		return
	}
	defer file.Close()

	a.logger.WithFields(logging.Fields{
		"filename": header.Filename,
		"size":     header.Size,
	}).Info(ctx, "Received file for upload")

View on GitHub (pinned to 35bff19146)

Solutions

Check the file size before upload and reject/truncate oversized files client-side
Raise ARGO_SERVER_MAX_ARTIFACT_UPLOAD_BYTES in the argo-server deployment if larger uploads are intended (document in docs/environment-variables.md)
Compress or split the artifact, or upload via the storage backend (S3/GCS) artifact path instead
Ensure proxies/ingress also allow the intended body size

Example fix

# before (client sends 2GB file with default 1GiB cap)
curl -X POST -F 'file=@huge.bin' ...
# after
ARGO_SERVER_MAX_ARTIFACT_UPLOAD_BYTES=4294967296  # 4GiB in argo-server env
# or client-side:
stat -c%s huge.bin  # verify <= cap before upload

Defensive patterns

Strategy: validation

Validate before calling

size := fileInfo.Size()
cap := int64(1 << 30) // or configured ARGO_SERVER_MAX_ARTIFACT_UPLOAD_BYTES
if size > cap {
    return fmt.Errorf("artifact %d bytes exceeds upload cap %d", size, cap)
}

Try / catch

if resp.StatusCode == http.StatusRequestEntityTooLarge {
    return fmt.Errorf("upload exceeds ARGO_SERVER_MAX_ARTIFACT_UPLOAD_BYTES; compress or split the artifact")
}

Prevention

Check file size client-side against the configured cap before uploading
Keep server cap and any ingress body limits aligned
Prefer direct artifact storage (S3/GCS) for very large files
Document the env var when raising it so ops know the new limit

When it happens

Trigger: Uploading an artifact larger than the configured cap; the client not honoring Content-Length limits mid-stream; an intermediary sending a body exceeding the limit.

Common situations: Large binaries (datasets, videos) uploaded through the artifact endpoint; operator lowered ARGO_SERVER_MAX_ARTIFACT_UPLOAD_BYTES from the 1GiB default; misconfigured chunked upload that inflates apparent size.

Related errors

AI-assisted analysis of argoproj/argo-workflows@35bff19146 (2026-09-03). Data as JSON: /api/errors/b7ebf7a3c736614c. Report an issue: GitHub.