Pre-generate several view IDs to send with initial RPC

[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.

Currently, the initial delivery RPC includes one pre-generated ID for each of logUserID, sessionID, and viewID. Given the number of missing viewID events, we can probably cut down on this number by pre-generating more than one of these IDs for sending with initial delivery RPC.

Proposal

Instead of the current data being passed to the delivery RPC, ie.

{
  "logUserId": "<log-user-id>",
  "sessionId": "<session-id>",
  "viewId": "<view-id>",
}

We pass the next n pre-generated IDs that the mobile client will use in sequence.

{
  "logUserId": ["<log-user-id-1>", ..., "<log-user-id-n>"],
  "sessionId": ["<session-id-1>", ..., "<session-id-n>"],
  "viewId": ["<view-id-1>", ..., "<view-id-n>"],
}

In each case "<view-id-1>" will be equivalent to the currentOrPendingViewID as currently being passed. That is, if there is currently a view ancestor ID set, this will be that ID. Otherwise, it will be the ID that will be set the next time a view is logged.

Because these IDs depend on the state of the mobile client, there may be overlaps between these IDs as the session progresses.

This should provide backends with more chances to match against an ID in logged events. This is also more of a stopgap solution until we figure out why we're missing view IDs.

Also, since the problem is worse with view IDs, we could increase only the number of pre-generated view IDs (leaving log user and session IDs as before, at one each).

{
  "logUserId": "<log-user-id>",
  "sessionId": "<session-id>",
  "viewId": ["<view-id-1>", ..., "<view-id-n>"],
}

Sign off

Work begins when sign-off is received from all of the following:

• [ ] Andrew
• [ ] Dan
• [ ] Jin
• [ ] YW

[andrewdyates]

What happens if the view with view-id-1 item isn't logged, so the item is joined with view-id-2 which is logged, but view-id-2 is not related to the joined item?

[yunapotamus]

There's no guarantee that the item in the delivery RPC is actually related to view-id-1 either, since at the time the delivery RPC is made, no view may exist.

[yunapotamus]

Maybe I’m going about this the wrong way. Instead of logging the pending future IDs, maybe I should consider logging a view history with each batch. Like:

message MobileViewHistory {
  repeated event.View view = 1;
  int32 total_views_logged = 2;
}

message LogRequest {
  MobileViewHistory mobile_view_history = ...;
}

We can log the latest n 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.

[yunapotamus]

I'm going to close this issue out and open a new one to track ancestor ID history.