Upload and download sessions are not robust

[rubenhensen]

Any upload or download will crash with a missing chunk or some other reliability problem from network, client or server, making the user start over again.

[rubenhensen]

/dobby fix this issue

[rubenhensen]

/dobby fix this issue

[rubenhensen]

/dobby fix this issue

[rubenhensen]

/dobby fix this issue

[dobby-coder]

Dobby has seen the request, master rubenhensen! Dobby is reading the upload and download flow now to find what makes sessions fragile and will report back with a plan before changing any code.

[dobby-coder]

Dobby has read the upload/download flow in src/main.rs and src/store.rs. The issue as stated covers several distinct failure modes — some are already being fixed, others are not. Breaking them down so we can land them piece by piece:

1. Idle session evicted while client is mid-upload

The original Store::create schedules a hard 15-minute removal regardless of activity. Slow links or large files past 15 min hit a 404 on the next chunk PUT. Already fixed in PR #132 (draft, CI green): bumps the idle window to 60 min and resets it on each successful chunk write. Promoting #132 to ready will close half of this issue's pain.

2. Process restart loses all in-progress sessions

StoreState is in-memory only, so any restart wipes upload sessions and leaves orphan files on disk. Tracked separately as #116. This is the bigger architectural piece (SQLite or sled-backed Store, hydrate on boot). Out of scope for #132 by design.

3. Orphan files from upload_init on bad recipient

upload_init creates the empty file before validating the recipient, so a malformed recipient leaves a zero-byte orphan. Already fixed in PR #131 (#125). Not directly the "missing chunk" symptom, but it contributes to the disk-side untidiness this issue describes.

4. No client-side resume protocol (the biggest missing piece)

This is what actually causes "missing chunk → start over". When a PUT /fileupload/<uuid> response is lost mid-flight:

• Client doesn't know whether the chunk was written server-side.
• The cryptifytoken chain has rolled to a value the client never received, so even a naive retry fails the token check.
• There is no GET endpoint to query session state (uploaded, current token), so the client has no way to recover and must abort.

Two complementary fixes possible:

• Status endpoint: GET /fileupload/<uuid>/status authenticated by an initial recovery token (stored once at upload_init), returning {uploaded, cryptify_token}. Client recovers and continues from the next chunk.
• Idempotent chunk retry: store prev_cryptify_token on FileState. If the client retries with the previous token and the same offset, verify the chunk hash and return the current token without re-writing. Handles one-step retries without exposing tokens via GET.

Either is a fairly self-contained change but does add a wire-protocol contract; the web/Outlook/Thunderbird clients also need updating to use it before users see the benefit.

5. Download robustness

/filedownload is served by Rocket's FileServer, which already supports HTTP range requests. The browser's native download handling can resume range downloads. No server-side change is obviously needed unless there's a specific download-side symptom we want me to investigate — let me know what the report looked like.

---

Proposed plan

1. Promote PR fix(store): extend upload session deadline on each chunk PUT #132 to ready (covers Add code from rust backend #1).
2. Open a new draft PR with a status/resume endpoint per Perform encryption in a Web/Service Worker #4 (server side only; client integration is a separate task per client app).
3. Leave Upload session state is not persisted; server restart causes 404 on chunk PUT and orphaned files on disk #116 (persistence) and Perform encryption in a Web/Service Worker #4 client integrations as separate work.

Master rubenhensen, does this match what you had in mind, and which of the two #4 designs (status endpoint vs. idempotent retry) do you prefer? Once you confirm, this agent will start on the chosen one.