Staging instance, all changes can be removed at any time

Skip to content

Only record last_visited and last_successful in origin_visit_stats

Nicolas Dandrimont requested to merge generated-differential-D6018-source into generated-differential-D6018-target

After using this schema for a while, all queries can be implemented in terms of these two timestamps, instead of the four original last_eventful, last_uneventful, last_failed and last_notfound timestamps.

This ends up simplifying the logic within the journal client, as well as that of the grab_next_visits query builder.

To make this change work, we also stop considering out of order messages altogether in journal_client. This welcome simplification is an accuracy tradeoff that is explained in the updated documentation of the journal client:

.. [1] Ignoring out of order messages makes the initialization of the origin_visit_status table (from a full journal) less deterministic: only the last_visit, last_visit_state and last_successful fields are guaranteed to be exact, the next_position_offset field is a best effort estimate (which should converge once the client has run for a while on in-order messages).

Test Plan

everything is awesome

Migrated from D6018 (view on Phabricator)

Merge request reports