[Majeur] GET /me renvoie toujours channelsAckMsg vide : l'état de lecture n'est jamais rechargé #100

New issue

Closed

opened 2026-10-28 10:31:59 +00:00 by asventi · 0 comments

asventi commented

2026-10-28 10:31:59 +00:00

Owner

Gravité : Majeur
Rapports QA d'origine : CHAT-17

TokenContext ne fait pas Include(ChannelsAckMsg) : après refresh, aucun non-lu ni divider « New messages ».

Détails des rapports

[CHAT-17] L'état de lecture n'est jamais rechargé : `GET /api/me` renvoie toujours `channelsAckMsg: {}` — Gravité : Majeur

Où : GET /api/me, divider "New messages", POST /channels/{id}/messages/{msgId}/ack.
Étapes : 1. bob : POST /channels/<ch>/messages/<msgId>/ack -> 204 (aussi déclenché par l'UI à l'ouverture d'un channel). 2. GET /api/me.
Attendu : channelsAckMsg contient {<channelId>: <date>}. Obtenu : {} (vérifié après ack API 204 et après lecture dans l'UI). Conséquence : après un refresh/une nouvelle session, le front ne connaît aucun ack (useAckTime -> null) : le divider "New messages" ne peut jamais s'afficher à partir de l'état serveur, et chaque ouverture ré-envoie des acks.
Cause probable : backend/API/Middlewares/TokenContext.cs charge l'utilisateur avec .Include(u => u.Role).Include(u => u.Avatar) mais pas .Include(u => u.ChannelsAckMsg) ; Users/Me/Get/GetMeEndpoint.cs ("No handler: touches no database") convertit une collection non chargée.
Complément : même en navigation SPA (Home -> retour sur le channel avec 2 nouveaux messages d'un autre user après un ack), le divider "New messages" n'est apparu dans aucune de 3 tentatives (16 échantillons sur ~2 s) ; cause non identifiée côté front (chat/components/Messages/MessageList.tsx useNewMessagesDividerId) -> à vérifier. L'ack n'est d'autre part envoyé à la première ouverture qu'après un évènement focus fenêtre (en headless : possible artefact, car document.hasFocus() conditionne useReadReceipts).

Trouvé par une campagne de tests QA automatisés (agents Claude, Playwright) sur l'environnement de dev. Les captures citées sont locales et non jointes.

**Gravité :** Majeur **Rapports QA d'origine :** CHAT-17 `TokenContext` ne fait pas `Include(ChannelsAckMsg)` : après refresh, aucun non-lu ni divider « New messages ». ## Détails des rapports <details><summary>[CHAT-17] L'état de lecture n'est jamais rechargé : `GET /api/me` renvoie toujours `channelsAckMsg: {}` — Gravité : Majeur</summary> - Où : `GET /api/me`, divider "New messages", `POST /channels/{id}/messages/{msgId}/ack`. - Étapes : 1. bob : `POST /channels/<ch>/messages/<msgId>/ack` -> 204 (aussi déclenché par l'UI à l'ouverture d'un channel). 2. `GET /api/me`. - Attendu : `channelsAckMsg` contient `{<channelId>: <date>}`. Obtenu : `{}` (vérifié après ack API 204 et après lecture dans l'UI). Conséquence : après un refresh/une nouvelle session, le front ne connaît aucun ack (`useAckTime` -> null) : le divider "New messages" ne peut jamais s'afficher à partir de l'état serveur, et chaque ouverture ré-envoie des acks. - Cause probable : `backend/API/Middlewares/TokenContext.cs` charge l'utilisateur avec `.Include(u => u.Role).Include(u => u.Avatar)` mais pas `.Include(u => u.ChannelsAckMsg)` ; `Users/Me/Get/GetMeEndpoint.cs` ("No handler: touches no database") convertit une collection non chargée. - Complément : même en navigation SPA (Home -> retour sur le channel avec 2 nouveaux messages d'un autre user après un ack), le divider "New messages" n'est apparu dans aucune de 3 tentatives (16 échantillons sur ~2 s) ; cause non identifiée côté front (`chat/components/Messages/MessageList.tsx` useNewMessagesDividerId) -> à vérifier. L'ack n'est d'autre part envoyé à la première ouverture qu'après un évènement `focus` fenêtre (en headless : possible artefact, car `document.hasFocus()` conditionne `useReadReceipts`). </details> --- _Trouvé par une campagne de tests QA automatisés (agents Claude, Playwright) sur l'environnement de dev. Les captures citées sont locales et non jointes._

asventi added the

bug

groupe/chat-data

labels

2026-10-28 10:44:16 +00:00