Chat attachment upload failures show two error messages — the generic one never says why (e.g. 10 MB limit)

[touzenesmy]

Prerequisites

• I searched open issues and discussions and did not find an existing report of this bug.
• This is not a security vulnerability. (Vulnerabilities go to GitHub Security Advisories — see SECURITY.md.)
• I am running the latest code from the dev branch (the default branch you get on clone, where fixes land first) and the bug still reproduces there. Please git pull the latest dev before filing.

Odysseus Revision

ce04dc1 (2026-09-01)

Install Method

Manual Python install (pip / venv)

Operating System

Linux

Steps to Reproduce

1. Keep the default chat upload size limit (10 MB — ODYSSEUS_CHAT_UPLOAD_MAX_BYTES unset in .env)
2. In a chat session, attach a file larger than 10 MB (tested with a 28 MB MP4)
3. Click Send
4. Watch the composer area (top-left) and the attachment strip area (bottom-center) as the upload is rejected

Expected Behaviour

A single error message in the composer that states the actual rejection reason, e.g.:

Upload failed: File size exceeds 10 MB limit. Attachment kept so you can retry.

Additionally, the size message should say the limit is configurable — it is (default 10 MB, overridable per-install via the ODYSSEUS_CHAT_UPLOAD_MAX_BYTES env var, documented in .env). As-is, users reading only the size message have no reason to know it is not a hard-coded wall.

Actual Behaviour

Two error messages fire from one rejection:

1. Top-left (composer toast): Upload failed. Attachment kept so you can retry. — generic, no reason
2. Bottom-center (inline attachment toast): Upload failed: File size exceeds 10 MB limit — the specific reason, shown in a different place, overlapping the generic message for a few seconds

So the reason the user needs is not where the user reads first, and the size message does not mention that the limit is configurable.

error10mb.mp4

Logs / Screenshots

No server-side error — `/api/upload` correctly returns HTTP 400 with a JSON `detail` payload. Both messages originate client-side: `static/js/fileHandler.js` (`_showToast` on the HTTP-error path) and `static/js/chat.js` (unconditional `showError` whenever `wasLastUploadCancelled()` is false).

Recording attached below: uploading a 28 MB MP4, both toasts fire in sequence.

Model / Backend (if relevant)

llama.cpp + qwen3.8-27b-q3kxl (client-side bug, model irrelevant)

Are you willing to submit a fix?

Yes — I can open a PR

Additional Information

• Searched open and closed issues for upload, attachment failed, file size, exceeds 10 MB, Attachment kept so you can retry — no existing report of this double-display bug. (File limit for uploads (both number and size) #4713 "File limit for uploads" is a separate enhancement request to raise/remove the limits themselves, not about error display.)
• Root cause (verified at ce04dc1d): two independent client UI paths fire from one failure — fileHandler.js toasts the server's reason, and chat.js unconditionally shows its own generic message on top.
• Fix prepared and tested locally (~12 lines across the two files): fileHandler.js stashes the server's reason instead of toasting it, and chat.js displays that reason in the composer message. Tested on the running instance with the same 28 MB MP4: exactly one toast — Upload failed: File size exceeds 10 MB limit. Attachment kept so you can retry.
• A PR referencing this issue will follow.