Log ancestor ID history as diagnostics

[yunapotamus]

Background

We've encountered several instances where the logUserID and viewID found in delivery RPCs don't match up with any logged client events. This is more common for viewID. This could be caused by the mobile client failing to send some events, but we have no way of knowing if this is the case in prod right now.

Proposal

To help diagnose where we're dropping ancestor IDs, we can log the history of these IDs from the client as part of the diagnostics we're sending through. This is intended as a short-term diagnostic tool only, and should be turned off when we get enough information to address the underlying issue.

Schema

message LogUserIdHistoryItem {
  oneof {
    // Logged event
    event.User logged_user_event = 1;
    // External ID
    string external_user_id = 2;
  }
  // Which batch number the event was logged in
  int32 batch_number = 3;
}

// Similar for SessionIdHistoryItem, ViewIdHistoryItem

message AncestorIdHistory {
  // Window of latest 10 log user ids
  repeated LogUserIdHistoryItem log_user_id_history = 1;
  // Total number of log user ids logged this session
  int32 total_log_user_ids_logged = 2;
  // Same for session id
  repeated SessionIdHistoryItem session_id_history = 3;
  int32 total_session_ids_logged = 4;
  // Same for view id
  repeated ViewIdHistoryItem view_id_history = 5;
  int32 total_view_ids_logged = 6;
}

message MobileDiagnostics {
  AncestorIdHistory ancestor_id_history = m;
}

message LogRequest {
  MobileDiagnostics mobile_diagnostics = n;
}

We can log the latest 10 (configurable) views as a window.

This would give more context around each view and allow us to figure out which views might not be related to the RPC. We'd have the timestamps of the potentially missed views.

Mobile client

Add the following parameter to ClientConfig:

public class ClientConfig {
  public var diagnosticsAncestorIDHistorySize: Int = 0
}

If this parameter is >0, then the client will maintain and send the AncestorIdHistory message inside MobileDiagnostics on LogRequest.

[prm-dan]

These fields look fine.

If you want more info on the initial load use case, it's fine to log a special diagnostic record around the initial load (with extra IDs and stuff).

I pushed back on the previous approach because it was a bunch of info that seemed redundant. If it's just initial page load focused, that's fine.

[yunapotamus]

Gotcha. I think I'll hold off on the initial record with the upcoming IDs for now, since this should hopefully contain the same information but in a more usable format.