From 37c715980146fec746f7b96f219a650e0b76e1fc Mon Sep 17 00:00:00 2001 From: moojttaba Date: Thu, 4 Jun 2026 00:40:16 +0330 Subject: [PATCH] =?UTF-8?q?docs:=20activity=20log=20=E2=80=94=20backend=20?= =?UTF-8?q?v2.8.74=20(chat=20uuid=E2=86=92session=20ObjectId=20participant?= =?UTF-8?q?=20fix)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 4.8 (1M context) --- 09 - Audits/Activity Log.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/09 - Audits/Activity Log.md b/09 - Audits/Activity Log.md index d532389..41f5d77 100644 --- a/09 - Audits/Activity Log.md +++ b/09 - Audits/Activity Log.md @@ -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. + +--- +