bug: attachment upload notifications are shown again in other channels after switching channel
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 52/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- react, typescript
- Ambito
- frontend
Direzione di ricerca
Segui NotificationList attraverso MessageList e VirtualizedMessageList, quindi esamina components/Notifications/notificationTarget.mjs e il middleware delle notifiche degli allegati descritto nell’issue. Verifica in che modo il cambio di canale rimonta la lista mentre client.notifications rimane globale. Il lavoro è completato quando una notifica di caricamento dal canale A non viene renderizzata nuovamente nel canale B, inclusi i caricamenti bloccati e falliti.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Describe the bug
An attachment upload notification raised in channel A (e.g. validation:attachment:upload:blocked when a file exceeds the upload size limit) is displayed again in channel B after the user switches channel, even though channel B has no upload at all.
The notification itself is only created once — I patched client.notifications.add and confirmed exactly one validation:attachment:upload:blocked entry. What happens is that the same still-alive notification is re-rendered by the newly mounted NotificationList:
client.notifications is a single global store (NotificationManager), not scoped per channel.
NotificationList is rendered by MessageList / VirtualizedMessageList, i.e. inside . Switching the active channel unmounts that list and mounts a new one, which renders whatever is still in the global store.
Panel targeting only distinguishes panel type: isNotificationForPanel() reads target: tags and otherwise falls back to "channel" (components/Notifications/notificationTarget.mjs). There is no scoping by channel instance.
The auto-dismiss timer only starts once a list renders the notification and it is at least 50% visible (IntersectionObserver in NotificationList), so within its 3s lifetime a channel switch shows it again in the new channel.
Integrators cannot filter it out either: the notifications emitted by AttachmentManager carry no channel identity. createBlockedAttachmentUploadNotificationMiddleware sets origin.context = { blockedAttachment } and createUploadErrorHandlerMiddleware sets origin.context = { attachment } — no channel_cid, no composer reference.
Point 5 is the part that makes this unworkable from user land, so I filed it here rather than working around it. The same applies to api:attachment:upload:failed.
To Reproduce
Open channel A and attach a file larger than the upload size limit (default 100 MB).
The toast "Attachment upload blocked due to size limit" appears — correct.
Within ~3 seconds, click channel B in the channel list.
The same toast appears again in channel B, which has no attachment and no upload in progress.
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Package version
stream-chat-react: 14.12.0
stream-chat-css: 5.16.1
stream-chat-js: 9.52.0
- Lingua principale
- TypeScript
- Stelle
- 845
- Fork
- 297
- Merge medio
- 1g 3h
- PR unite (30g)
- 24
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di GetStream/stream-chat-react
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 73/100
GetStream/stream-chat-react#3311 ·
I maintainer di solito rispondono entro 1 giorno
-
bug status:confirmed WIP
Difficoltà 3/5 1-2 giorni Idoneità per principianti 62/100
GetStream/stream-chat-react#3147 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
bug status: unconfirmed
Difficoltà 3/5 1-2 giorni Idoneità per principianti 38/100
GetStream/stream-chat-react#2863 · 4 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
bug status:confirmed
Difficoltà 3/5 1-2 giorni Idoneità per principianti 30/100
GetStream/stream-chat-react#2652 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
bug status: unconfirmed
Difficoltà 4/5 3-5 giorni Idoneità per principianti 42/100
GetStream/stream-chat-react#2647 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di GetStream/stream-chat-react
Issue simili
-
Remove the landing pageApertaby: ai-assisted frontend good-for: new-member spike
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
Northeastern-Electric-Racing/Argos#847 ·
I maintainer di solito rispondono entro 4 giorni
-
Difficoltà 1/5 1-3 ore Idoneità per principianti 84/100
SignalK/freeboard-sk#990 ·
I maintainer di solito rispondono entro 1 giorno
-
[missing-inheritance] audit review (1 preset)Forse già presa @github-actions l’ha presa oggi. Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 82/100
osmberlin/tagging-schema-browser#363 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
Albert-Weasker/niubigeo#205 ·
I maintainer di solito rispondono entro 1 giorno
-
area/frontend area/v2 kind/bug priority/needs-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
kubeflow/notebooks#1498 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno