Follow-up to {T263051}. That task documented slight inconsistencies in the numbers of events sent by the same instrumentation to the legacy and modern event intake systems. In theory, the numbers should be identical, but the observed results showed a slight discrepancy in the numbers of events sent, with more events making it to the legacy than the modern system.
> The very minor differences in counts across the different types of interactions with the Edit History Compare feature are a little weird:
>
> | action | n_total_legacy_events | n_total_modern_events | percent_difference (new-old)/old |
> |---|---|---|---|
> | show_history | 2369 | 2309 | -2% |
> | thank_fail | 15 | 15 | 0% |
> | thank_success | 16 | 16 | 0% |
> | revision_view | 4183 | 4127 | -1% |
> | compare2 | 72 | 69 | -4% |
> | thank_try | 57 | 57 | 0% |
> | compare1 | 177 | 174 | -1% |
>
> We need to investigate why the instrumentation ([[ https://github.com/wikimedia/wikipedia-ios/blob/34270d2cd0ea1b170cde753f9904e8b5cda75d49/Wikipedia/Code/EditHistoryCompareFunnel.swift | EditHistoryCompareFunnel.swift ]]) produces fewer MEP events in some cases.
The leading hypothesis explaining this discrepancy is that the MEP client did not re-implement the unique storage model used by the iOS app for legacy eventlogging. For legacy eventlogging, unlike other platforms, the iOS app immediately stores events to a database table of pending events, then tries periodically to submit them for a period of up to 30 days. As part of {T261987}, this pattern was reimplemented in the MEP client in order to test whether doing so would resolve the discrepancies.