matze/docs
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Auto saved by Logseq

Browse Source
This commit is contained in:
Matthias Eckert 2023-03-06 16:16:30 +01:00
parent 67e10fed33
commit 97619d124d
1 changed files with 2 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
journals/2023_03_06.md
View File

@ -38,4 +38,5 @@
- What is createdAt referring to? (I assumed it’s the time the event happened, but then later IDs should have higher timestamps) Why can it be decreasing in events with later IDs. How does it relate to the document timestamps (we established in earlier conversations that document updatedAt can differ from event createdAt because they are different processes)
How am I supposed to know if I got all events if there are missing ones and timestamps and/or IDs are not monotonically increasing?
- Ich glaub bei dem Beispiel das er anführt hatten wir die Probleme mit Kubernetes im RZ und da ist dann beim Neustarten der Event Verarbeitung auch der Offset wieder auf einem alten Wert gelandet. Beim Check der letzten 24310 Events (139470000 -> 139494310) gab es den Effekt nicht. Die Annahme von Ihnen stimmt also im Normalfall.
- Also if you replay events, do you also replay data, so is e.g. document 7a233a97-1f18-3792-b287-c7b35f601f0b also not yet updated on the documents endpoint and we need to wait 15 minutes from some timestamp (in that case no idea how to figure that out instead of retrying for some time) for this to update?
- Also if you replay events, do you also replay data, so is e.g. document 7a233a97-1f18-3792-b287-c7b35f601f0b also not yet updated on the documents endpoint and we need to wait 15 minutes from some timestamp (in that case no idea how to figure that out instead of retrying for some time) for this to update?
- Versteh ich nicht, wir replayen typischerweise kein Dokumentveränderungsevents, sondern haben wie oben