Under what circumstances would initial_replication_date be unknown

Technical Support
1

Hello,

I’m looking at sync times for report submissions in January, and for most submissions initial_replication_date is populated with an ISO formatted date. However, a very small minority (0.01%) has ‘unknown’ value for initial replication date. I’m curious about scenarios that could be causing this behavior.

2

Can you post a sample infodoc that you’re seeing? What do you mean ‘unknown’ value?

3

Value is literally ‘unknown’. Here’s a sample document:

{
  "_id": "862606a5-52d7-4421-b33c-74d19fee5bc6-info",
  "_rev": "3-f9da37dd3d3e0a768985ced4858360ef",
  "type": "info",
  "doc_id": "862606a5-52d7-4421-b33c-74d19fee5bc6",
  "initial_replication_date": "unknown",
  "latest_replication_date": "2025-02-05T10:48:54.030Z",
  "transitions": {}
}
4

I believe this would be only be caused by a race condition where the doc is processed by sentinel in very quick succession after being created.

We create infodocs async in API, when docs are pushed. So the doc is written to the medic db first, and then the infodoc gets created and saved in medic-sentinel. If sentinel processes the doc before the initial infodoc write, this can happen.

This is extremely unlikely.

3 Likes
5

From our sampling of docs, it happened for 5 reports out of 15115 reports for Nairobi in Jan. It didn’t happen at all in Nov or Dec (roughly same sample size of docs).

Would more API restarts increase likelihood? If an infodoc write is queued and the service goes down, then it would never get written?

6

Yes.

Since there are no transactions in CouchDb, this is effective for any database interaction in the CHT.