[Max-Reisinger]

Pull Request Type

• Bug fix

Relevant Issues

Resolves #7114

Description

If the workspace upload request rejects or a proxy returns an HTML error page, the file row stays pending and its timer keeps running. The row now shows an upload failure for either case and still displays the server's message for JSON errors. It clears the elapsed-time timer when the request settles or the row unmounts, and only schedules dismissal while mounted.

Developer Validations

• cd frontend && yarn lint:check
• A local React regression harness using the upload row and upload model reproduced the failure on master. With this change, a rejected fetch and an HTML 502 both show a failure and stop the timer. JSON success and error responses still work. Unmounting during a pending upload stops the timer, and a late response does not schedule dismissal.
• To reproduce in the app, wait for the document picker to become ready, switch DevTools network to Offline, and select a small text file. The row should show an error instead of spinning.

[timothycarambat]

Thanks for this. The hang is real, but the trigger is different from the one described, and the fix needs to go one layer down.

When this actually happens

Offline/collector-down isn't really reachable: the dropzone stays disabled until the collector reports online, and if it goes down later the upload route returns a JSON 500, which the row already handles. The case that does hit this is a reverse proxy in front of AnythingLLM:

• nginx's default 60s proxy_read_timeout returns an HTML 504 while the collector is still processing a large or OCR-heavy PDF (the server deliberately waits up to 10 minutes for the collector).
• nginx's default 1MB client_max_body_size returns an HTML 413.

Both leave the row spinning forever, because the body isn't JSON.

Where the fix belongs

The root cause is in the model, not the row: Workspace.uploadFile, uploadLink, and parseFile all call response.json() without handling errors, so every caller is affected. With a non-JSON 500, uploadLink throws before setFetchingUrl(false) runs, so the link input stays disabled, and parseFile throws the same way for chat drag-and-drop attachments. Patching FileUploadProgress leaves those two broken.

Could you rework this so that:

1. The three model methods catch network errors and non-JSON bodies and always resolve { response, data }. Build data.error from the status (e.g. 504 Gateway Timeout, 413 Request Entity Too Large) instead of a generic string, so the user can tell a timeout or a too-large file from a broken upload.
2. The catch blocks in the upload and upload-link routes return JSON ({ success: false, error: e.message }) instead of sendStatus(500), so our own errors surface their message too.
3. FileUploadProgress goes back to the existing timers ref for cleanup and drops the closure-variable refactor. With (1), the request always resolves, so the interval is cleared after the await, and master already clears its timeouts on unmount.

With those changes the component diff should be close to empty: keep data?.error as a guard, plus whatever you need to show the new status-based messages.