myxelium/Toju
1
0
Fork 0
Code Issues 16 Pull Requests Actions Packages Projects 2 Releases 39 Wiki Activity

fix: Bug - Sending files and attachment issues

Browse Source 
Hydrate playable media after disk receive, relay file-announce to sibling
devices via account_sync, bind DM attachments to pre-allocated message ids,
and improve gallery retry/cancel UX with bounded parallel auto-downloads.

Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
myxelium
2026-06-14 13:05:23 +02:00
co-authored by Cursor
parent bb0ac930ad
commit fa45052432
30 changed files with 785 additions and 71 deletions
Download Patch File Download Diff File Expand all files Collapse all files
toju-app/src/app/domains/direct-message/README.md
+6 -5
View File
@@ -21,11 +21,12 @@ direct-message/
## Flow
1. `DirectMessageService.sendMessage()` stores the message locally with `QUEUED`.
2. `PeerDeliveryService` tries to send a `direct-message` P2P event to every other participant's current peer id.
3. If no data channel is connected, `PeerDeliveryService` tries each participant's known signaling route before leaving the message queued.
4. If either transport sends, the sender advances to `SENT`; otherwise the message id remains in `OfflineMessageQueueService`.
5. The recipient persists the message as `DELIVERED` and sends a `direct-message-status` event back.
6. Opening the conversation marks incoming messages as `ACKNOWLEDGED` and emits a status event.
2. `DmChatComponent.handleMessageSubmitted` pre-allocates the outgoing message id via `planDmMessageSend` (`domain/rules/dm-message-send.rules.ts`), passes it to `sendMessage(..., id)`, and binds pending files to that **same** id with `AttachmentFacade.publishAttachments`. Never attach after `sendMessage` resolves by re-discovering the message — caption-less media races the async create path the same way server rooms used to.
3. `PeerDeliveryService` tries to send a `direct-message` P2P event to every other participant's current peer id.
4. If no data channel is connected, `PeerDeliveryService` tries each participant's known signaling route before leaving the message queued.
5. If either transport sends, the sender advances to `SENT`; otherwise the message id remains in `OfflineMessageQueueService`.
6. The recipient persists the message as `DELIVERED` and sends a `direct-message-status` event back.
7. Opening the conversation marks incoming messages as `ACKNOWLEDGED` and emits a status event.
Unread counts are idempotent by message id: re-receiving or syncing a message that already exists can update status/content metadata but must not increment the conversation unread count again.