fix: Restore chat attachments after reload

Wait for persisted attachment metadata before serving or advertising files so reconnecting peers can load images and downloads reliably.

Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
2026-07-14 10:29:37 +02:00
co-authored by Cursor
parent d3d22846e7
commit 41ebaf2407
5 changed files with 131 additions and 5 deletions
@@ -117,6 +117,8 @@ If the sender cannot find the file, it replies with `file-not-found`. The transf
Peers that finish downloading a file re-announce it and register themselves as mirror hosts. New download requests prefer mirror hosts over the original uploader so the sharer's device is not the only upload source. Repeat `file-announce` events for already-known attachments update the host list but do not re-trigger auto-download. Outgoing `file-announce` broadcasts are also relayed to sibling devices through `account_sync` (see `infrastructure/realtime/account-sync/account-sync.rules.ts`) so a second client of the same user learns attachment metadata even when it cannot P2P to itself.
After reload, serving and re-announcing wait for persisted attachment metadata to finish hydrating. Hosted files are announced even when the uploader is not currently viewing a room, so reconnecting peers can discover them from dashboard and other non-chat routes. If only an original Electron file-picker path survived, the first request copies that file into app data before streaming it; a request must not receive `file-not-found` merely because it raced startup hydration.
```mermaid
sequenceDiagram
participant R as Receiver