Update usage information metrics for v2024.2

[matthew-white]

Usage information metrics to add/remove/update

Add metrics for the following:

• 1. Number of offline branches involving more than one update
  • Probably also include offline branches with a single update if the trunk version is null. In that case, the branch follows an offline create.
  • Maybe something like: SELECT COUNT(DISTINCT "branchId") FROM entity_defs WHERE "branchId" IS NOT NULL AND ("trunkVersion" IS NULL OR "branchBaseVersion" > "trunkVersion")
• 2. How many branches were interrupted in the middle of being processed? That is, for how many branches was there an update from another source that was processed between when two updates from the branch were processed? To keep things simple, exclude branches where one of the updates was force-processed.
  • Matt: It's probably OK not to include the case where an interweaving update is made between an offline create and an offline update that follows it (an update where the trunk version is null).
• 3. How many submissions were put in the backlog just long enough for updates to be processed in the correct order? In other words, how many submission.reprocess events have there been?
• 4. How many offline updates have been force-processed?
  • Should this include an offline update force-processed before the offline create? I.e., an offline update applied as a create?
  • Moved to Update usage information metrics for v2024.3 #722
• 5. How long does it take for an entire branch to be processed? Specifically: what is the max amount of time between when the first submission for a branch is received and when the last submission is processed?
  • Exclude branches where one of the updates was force-processed. We're more interested in the more normal case where a submission is put in the backlog just long enough for updates to be processed in the correct order. In other words, we expect the max amount of time to be less than 5 days (hopefully much less!).
  • Moved to Update usage information metrics for v2024.3 #722
• 6. Taking a step back, how long does it take for an entity change to be processed when it's not part of an offline branch? Are we seeing processing backlogs? Specifically: for entity versions whose source is a submission and that are not part of a branch, what is the max amount of time between when the submission was created and the entity version was created? Let's exclude entity creates when submission approval was required. Or maybe let's always exclude entity creates and just focus on entity updates.
  • Matt: Is this actually a helpful metric now that all updates via submission will technically be offline updates? What I'm personally interested in is some sense of how often there are long delays in entity processing due to a large number of unprocessed events in the audit log. How often are the workers working through the audit log overworked? Maybe we should include offline updates in this query after all, but only offline updates that are the first in the branch (where branchBaseVersion === trunkVersion). The processing of such updates would never be delayed by the submissions being held in the offline entities backlog, only by a general backlog/build-up in the audit log.

Remove the following metrics:

• (none)

---

Checklist

• Update the form version string in the Backend config.
• Publish the new form version on data.getodk.cloud.
• Update the usage report in Frontend.