🐛(frontend) warn before uploading a file over the size limit

[RISK-alt]

Purpose

Fixes #2460

Dropping a file over the limit into the editor shows the bare "unknown error" from the issue's screenshot. Two things are missing.

Nothing checks the size before sending. The backend does enforce DOCUMENT_IMAGE_MAX_SIZE in FileUploadSerializer.validate_file, but the setting is not part of /api/v1.0/config/, so the frontend has nothing to check against. The user waits for the whole upload before learning it was refused — and with nginx in front, the request never even reaches Django.

And the 413 carries no readable cause. errorCauses parses the body unconditionally:

const errorsBody = (await response.json()) as Record<string, string | string[]> | null;

nginx answers its 413 with an HTML error page, so response.json() rejects, errorCauses throws instead of returning, and APIError is never built. The editor is left with an error carrying no cause, which is what it renders as "unknown error".

Proposal

• expose DOCUMENT_IMAGE_MAX_SIZE in the config endpoint, next to CONVERSION_FILE_MAX_SIZE which the import feature already uses that way
• check the file size in useUploadFile before calling the API, and show an error toast naming the file and the limit — same wording as the document import, so both paths read alike
• make errorCauses tolerate a body it cannot parse rather than throwing, which fixes every proxy-level error, not just this one
• map a 413 with no usable cause to an explicit message, so instances whose proxy limit is lower than DOCUMENT_IMAGE_MAX_SIZE still get something readable

The size-formatting logic was inlined in useImport; it moved to formatFileSize in utils/string.ts and is now shared by both call sites rather than copied.

This follows what 🛂(frontend) use max size and extension from config (b8bdcbf) did for the import feature: same shape, same set of files.

I did not touch translations.json — the English source strings are picked up by the Crowdin sync.

Testing

Added:

• formatFileSize unit tests
• an errorCauses test for a non-JSON body
• useUploadFile tests: a file under the limit reaches the API, a file over it is rejected with the toast and no request at all

Full impress suite on Node 26: 284 passing. Four failures in features/auth/__tests__/utils.test.tsx and docs-grid/components/__tests__/DocsGridItemDate.test.tsx are pre-existing — they fail identically on a clean main here, localStorage not being available under my local Node. tsc --noEmit and eslint are clean.

Note for reviewers: CONFIG in apps/e2e/__tests__/app-impress/utils-common.ts had to gain the new key, since config.spec.ts asserts toStrictEqual(CONFIG) against the live payload.

External contributions

General requirements

• I have read and followed the contributing guidelines
• I have read and agreed to the Code of Conduct
• I have added corresponding tests for new features or bug fixes (if applicable)

CI requirements

• I made sure that all existing tests are passing — front-end suite is green locally, waiting on the CI for the back-end and the e2e
• I have signed off my commits with git commit --signoff (DCO compliance)
• I have signed my commits with my SSH or GPG key (git commit -S)
• My commit messages follow the required format: <gitmoji>(type) title description
• I have added a changelog entry under ## [Unreleased] section (if noticeable change)

AI requirements

• I used AI assistance to produce part or all of this contribution
• I have read, reviewed, understood and can explain the code I am submitting
• I can jump in a call or a chat to explain my work to a maintainer

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 4867914c-9c15-4965-88fe-eaf79433dbde

📥 Commits

Reviewing files that changed from the base of the PR and between 5e4e995 and 1591f94.

📒 Files selected for processing (1)

• CHANGELOG.md

---

Walkthrough

The config endpoint now exposes DOCUMENT_IMAGE_MAX_SIZE. Frontend configuration types and test fixtures include this value. A shared formatFileSize utility formats size limits for document import. Uploads above the configured limit are rejected before the request, with a localized toast. HTTP 413 responses without usable causes now receive localized file-size feedback. Tests cover configuration, formatting, non-JSON responses, and upload validation.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Suggested reviewers: antolc

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly describes the main change: warning users before uploading files that exceed the size limit.
Description check	✅ Passed	The description directly explains the large-file upload bug, proposed fixes, implementation scope, and tests.
Linked Issues check	✅ Passed	The changes satisfy issue #2460 by validating file size before upload and providing readable feedback for oversized files and 413 responses.
Out of Scope Changes check	✅ Passed	The configuration, error handling, formatting utility, tests, changelog, and e2e updates all support the stated upload-size feedback objectives.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[AntoLC]

Duplicate of #2522