Eseményvezérelt keresési és ütemezési nézetek
A postafiók-nézetek események alapján frissítik a keresési előzményeket, a találatokat, a mentett kereséseket, az ütemezéseket és az automatikus rendezés haladását. A Szinkronizálási központ műveleti és ütközési frissítése, valamint a passzív rendezés állapotfrissítése külön működik.
A böngésző adatolvasásai
| Adat | Kezdeti olvasás | Későbbi olvasások |
|---|---|---|
| Keresési előzmények | A fiókeseményre való feliratkozás után | Ismeretlen keresés jogosultsága, helyi művelet, újracsatlakozás |
| Keresési találatok | A kiválasztott keresés megnyitásakor | Élő esemény, rés- vagy befejezés-pótlás, újracsatlakozás |
| Mentett keresések | A keresés megnyitásakor | Mentés, átnevezés, törlés, helyi művelet, újracsatlakozás |
| Ütemezések | A fiók nézetének megnyitásakor | schedule.changed, sync.recovered, helyi művelet, újracsatlakozás |
| Automatikus rendezés haladása | Kezdeti, fiókhoz kötött állapotolvasás | appProcessProgress, újracsatlakozás |
Ezek az eseményvezérelt nézetek WebSocket-kiesés alatt nem használnak tartalék-lekérdezést. Az utolsó ismert állapotot mutatják. Újracsatlakozáskor a hitelesített HTTP-olvasások visszaállítják a megfigyelt fiókokat. A böngésző-kapcsolat megszakadása nem állítja le a backend feldolgozását.
A passzív keresési komponensek a cache-t a useSyncExternalStore segítségével figyelik, aktív QueryObserver nélkül. Egy üres keresési azonosító nem indít keresést. Nem hoznak létre passzív skipToken megfigyelőt egy aktív lekérdezés kulcsán. A helyi feliratkozás-készültségi állapot külön marad. A stabil automatikus rendezési callbackek megakadályozzák, hogy a levéllista újrarenderelése újraindítsa az állapotolvasást.
Egy másik fiók eseménye, egy régi válasz vagy egy régi befejezési időzítő nem írhatja felül az újabb állapotot.
Keresési találatok helyreállítása
A csatlakoztatott fiók azonosítója jelöli a böngésző hitelesített fiókválasztását. A keresési esemény userId mezője a backend postafiók-felhasználó azonosítója. A kettő nem cserélhető fel. Ismeretlen keresésnél a hitelesített BFF-előzmény-válasznak kell jogosultságot igazolnia, mielőtt az esemény bekerül az adott fiók cache-ébe.
Az élő kurzor a legutóbb megfigyelt eseményállapotot rögzíti. A pótlási kurzor csak akkor lép tovább, miután a kliens olvasta a tartós találatoldalakat. A WebSocket-érkezési sorrend és a magasabb élő kurzor önmagában nem bizonyítja, hogy minden találat megérkezett.
A kliens a tartós találatokon lapoz befejezéskor, észlelt réseknél, megnyitáskor és újracsatlakozáskor. A régebbi válaszok nem vihetik vissza az újabb eseményállapotot. Egy QueryClienten belül egy fiók megosztja a figyelőjét és a törölt keresések nyilvántartását.
Az eseményvezérelt HTTP-olvasások összevonódnak. Az olvasás közben érkező esemény utólagos olvasást vált ki. A törölt keresések nem térhetnek vissza egy régebbi válaszon keresztül.
A fiók újbóli megnyitásakor a rendszer egyszer újraolvassa az előzményeket és a mentett kereséseket, mert az események a leiratkozás alatt is érkezhettek. Az ütemezési nézet megnyitása is aktuális állapotot olvas. Ez belépési olvasás, nem időzített lekérdezés.
Ütemezési eseményszerződés
A UserRealtimeSyncEventV1.eventType értéke schedule.changed.
| Payload-mező | Jelentés |
|---|---|
scheduleId | Az ütemezés UUID-ja |
draftId | A piszkozat stabil azonossága |
status | Az aktuális ütemezési állapot |
revision | A kért ütemezési revízió |
A boríték scope mezője tartalmazza a bérlő, a postafiók és a felhasználó azonosítóját. A correlationId az ütemezés azonosítója. Az esemény nem tartalmaz üzenettartalmat és címzetteket.
Az állapotváltozás és az outbox-bejegyzés ugyanabban a tranzakcióban történik. A kézbesítés a graphSyncNotifications, az InterfaceNotifier, az appRealtime és a hitelesített BFF WebSocket-kapcsolaton keresztül halad. A BFF a szerveren oldja fel a csatlakoztatott fiókot, és frissíti az email-schedules cache-t.
Az események lefedik az elfogadást, az átütemezést, a törlést, a worker-átmeneteket, a küldést, a hibákat, a helyreállítást és az Outlook-projekciót. A feltételes írások megtartják a revízió- és zárfeltételeket. Visszagörgetéskor az esemény is eltávolításra kerül. A változatlan, látható állapot újraellenőrzése nem bocsát ki újabb eseményt. Egy sikertelen küldési előfeltétel a feldolgozó hibát dobása előtt tartósan elmenti a hibát és az értesítést.
Outlook-törlésnél és átütemezésnél a kliens az elfogadás után egyszer olvas, majd eseményekre vagy újracsatlakozáskor ellenőrzi a kért revíziót. A 45 másodperces határidő pending állapotot ad vissza. Nem indít további módosítást, és a meg nem erősített munkát nem jelöli sikeresnek. Lásd: küldés törlése vagy átütemezése.