PatientChartActivity drops temporary observations prematurely.

[capnfabs]

See PatientChartActivityTest for reference.

Both of our tests that create multiple observations for a single patient in quick succession are flaky, and only pass about half of the time. The cause of the test failures appears to be that the chart fails to update after observations are made sometimes.

The failure mode for testCombinesNonOverlappingObservationsForSameEncounter is that sometimes, all of the observations from a single encounter are missing.

For testEncounter_latestEncounterIsAlwaysShown, sometimes the observations update to the new values, and sometimes they don't.

[llvasconcellos]

testEncounter_latestEncounterIsAlwaysShown test actually found a bug. I problem goes deeper and is documented here:
#85
#90

That's why PR #90 isn't merged yet. It should fix this behavior but it doesn't.

[capnfabs]

Thanks for the context! I suspect there's multiple issues here:

• The incremental sync issue that @zestyping sent PR Fix incremental fetch missing observations #90 for
• Whatever is causing that to not fix the problem that you're observing on the same PR.

[capnfabs]

OK. I think the problem is:

• Sync for Observations starts. Results are fetched, but JSON isn't parsed (yet).
• Simultaneously, the Xforms request is completed, and the success callback which adds the temporary records to the database is completed on the main thread.
• The JSON is parsed for Observations sync. The new records are added to the database, and the temporary records are deleted.

Thus, the temporary records are deleted without actually being used. This is why we see the flicker from the correct value back to the old value.

I'm not sure if this is the only cause but it's a start.

[capnfabs]

Another possible cause:

• the encounter_millis value we insert for temporary observations currently comes from the ODK form, which is truncated down to the minute. This means that the code that computes the latest observations will return a synced observation over a locally inserted observation every time.

[capnfabs]

The final possible cause:

• The code that requests periodic syncs runs the first one as soon as the chart is loaded. This drastically increases the probability that the first cause occurs.

[capnfabs]

From the Xforms code on the server:

That's a good place to start.

[llvasconcellos]

FIXME 😄

[capnfabs]

A couple of ideas as to how we can fix this:

• Pass the encounter UUID back from the server when an Xform is submitted. Save temporary observations with that UUID, and then only delete observations matching the encounter UUID. The problem with this approach is that we don't have a straightforward way of getting the Encounter UUID from the xform submission on the server, because the Xforms processor doesn't return any info about the form. We'd need to use a heuristic instead, like fetching the last created encounter and cross-checking the submission time.
• Add some kind of lock or mechanism whereby observation sync doesn't start until all pending Xforms have been submitted successfully. Note that @viniciusboson's [2016] Submit forms offline #172 includes this mechanism for offline form submission, but not for online form submission. This has the advantage of not requiring any heuristics on the server side, but does assume that after an Xform is submitted then the observations are immediately available for sync, which is an assumption we're careful not to make in the sync algorithm.