During bulk upload, if any file (e.g., a PDF) exceeds the 70 MB limit enforced by NGINX (client_max_body_size), NGINX rejects the request with HTTP 413. However, the Admin UI still displays a success message for the batch, as if the oversized file were uploaded. After refresh, the oversized file is absent (correct), but the messaging is wrong.

Note: Single-file uploads appear OK; this issue is observed in bulk flows.

Expected Behavior

For any file rejected by NGINX (413 due to client_max_body_size), the UI should show a clear error for that file, e.g.

“Upload failed: file.pdf exceeds server limit (70 MB).”

For mixed batches, show an accurate per-file status and a summary (e.g., “Uploaded 3/5 files. 2 failed due to size limit.”).

Only files within the limit should be marked success.

Actual Behavior

NGINX blocks the oversized file with 413, but the Admin UI shows a success message for the bulk operation.

The rejected file never appears in media (correct server behavior), but the UX is misleading.

Root Cause / Notes

The size restriction is enforced at the reverse proxy layer (NGINX), not by Payload itself.

NGINX’s default 413 response (often HTML, no JSON body) likely causes the client/bulk handler to treat the batch as “success” or to skip surfacing a per-file error.

This happens only in bulk uploads (needs confirmation for single-file path).

Link to the code that reproduces this issue

NA

Reproduction Steps

Steps to Reproduce

Go to Media / Uploads (or any collection with a file upload field).

Click Bulk Upload.

Select multiple files including at least one PDF >70 MB.

Start upload and wait for completion.

Observe the success toast even though NGINX rejected the oversized file (HTTP 413).

Which area(s) are affected? (Select all that apply)

Not sure

Environment Info

Dev, Staging, Testing, Production