Ottomata added a comment. > If we have a use case for emitting two secondary events *to the same topic* > that were both triggered by the same primary event (user click / request id), > then we can generate a new ID for at least one of those events, and record > the parent event id in a separate field (ex: par_id). This way, we can get > the right deduplication semantics for each of those events.
? What's the point of the request_id then? I thought we wanted X-Request-Id so that we can easily tie together events generated by the same http request. Why not just have `request_id` and `uuid` as separate fields that always exist? > IMHO, the timestamps of the event ID and explicit timestamp (ts or dt) should > always match. This makes it a lot simpler to automatically derive dt from id > in the producer REST proxy. Other event-specific times (like the save time as > recorded by MediaWiki) should imho go into the event body. Why? I agree, that specific schemas can define additional timestamps, but what is the harm in having a standard one that is set and used semantically by the producer? What if I wanted to explicitly feed a topic with events dated in the past, perhaps for backfilling or recovery reasons? TASK DETAIL https://phabricator.wikimedia.org/T116247 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: mobrovac, Ottomata Cc: EBernhardson, Smalyshev, yuvipanda, Hardikj, daniel, aaron, GWicke, mobrovac, MZMcBride, bd808, JanZerebecki, Halfak, Krenair, brion, chasemp, Eevans, mmodell, Ottomata, Mattflaschen, Matanya, Aklapper, JAllemandou, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, RobLa-WMF, jeremyb _______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
