Fix file-upload 404 on a brand-new chat#155
Merged
Merged
Conversation
The "+" button mints a client-only "virtual" session that isn't persisted in the DB until the first message is sent. Attaching a file to such a chat uploaded against that temp id, so POST /api/files/upload hit the handler's `if not session: 404 "Session not found"` guard — a 404 that looked like a missing route but was application-level. Extract a shared `ensureRealSession()` store action that materializes the virtual session (POST /api/sessions, adopt the server id, carry the draft across) and call it before uploading, so the upload targets a real session row. sendMessage now reuses the same action instead of its own inline materialization.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Attaching a file to a freshly-created chat fails. The browser console shows:
Root cause
It is not a missing route.
POST /api/files/uploadis registered and live (it's in the running app's OpenAPI; an unauthenticatedPOSTreturns401, not404). The404comes from inside the handler:The lazy "new chat" flow mints a virtual session — a client-only
randomUUID()(chatStorecreateSession) that is not persisted in the DB until the first message is sent. The code comment is explicit that this temp id "is never sent to the backend." But the file-upload path (ChatInput.addFiles→api.uploadFiles) fired immediately against that virtual id, so the backend — which had never seen it — returned404 "Session not found". This hits every attach-to-new-chat, i.e. the most common upload moment.Reproduced against a live server: uploading with a fake/virtual
session_id→404 "Session not found"; with a real persisted id →200.Fix
Materialize the virtual session before uploading, mirroring the existing first-message flow:
ensureRealSession(running?)store action — it POSTs/api/sessions, adopts the server-minted id, carries the unsent draft across to the new id (so the composer doesn't blank when the id swaps), and is a no-op once the chat is already real.ChatInput.addFilescallsensureRealSession()and uploads against the returned real id.sendMessagenow reuses the same action instead of its own inline materialization (single source of truth; send path keepsis_running: trueso the sidebar spinner is instant).Frontend-only; no backend or DB change. The session must genuinely exist (uploads are keyed by
session_idon disk and inuploaded_files), so materializing — not relaxing the guard — is the correct fix.Test plan
npm run build(tsc typecheck + Vite) passeseslinton both changed files: clean