docs: activity log — backend v2.8.74 (chat uuid→session ObjectId participant fix)
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -1123,4 +1123,20 @@ visible under their fields instead of only in the console.
|
|||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
### 2026-06-04 — backend v2.8.74 — chat: map uuid participants → session ObjectId (buyer↔seller fix)
|
||||||
|
|
||||||
|
Root cause confirmed from logs: a buyer opens a chat "with seller X" using X's
|
||||||
|
marketplace **Postgres uuid** (669c0dac-…), but X's session/JWT id is their
|
||||||
|
**legacy ObjectId** (e0527…). Conversations key participants by the session id,
|
||||||
|
so buyer and seller landed in two separate direct threads (each saw only their
|
||||||
|
own messages). ChatService.createChat now normalises any uuid participant (and
|
||||||
|
createdBy) → users.legacy_object_id via a direct PG lookup BEFORE dedup/create —
|
||||||
|
resolving TOWARD the session-id format (the reverted v2.8.72 resolved toward uuid
|
||||||
|
and broke membership). Both sides now converge on one conversation + socket room.
|
||||||
|
Note: pre-existing mismatched conversations are orphaned; a freshly opened chat
|
||||||
|
dedups correctly for both parties.
|
||||||
|
**Verification:** backend tsc clean.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
<!-- Add new entries above this line. Newest at top. -->
|
<!-- Add new entries above this line. Newest at top. -->
|
||||||
|
|||||||
Reference in New Issue
Block a user