App Version Conflicts

Users
1

Hi all,

I needed to understand something regarding released app versions and updates on CommCare (for android).

I have sampled some form JSON payload (in the repeater) and checked through the metadata to extract the app version used during the data collection, and I see different key-value pairs that all have app versions somewhere in the value. The issue however is that for some cases sampled, the app versions differ in the different key-value pairs. I am curious as to what could cause this.

Here’s part of the extracted payload for your reference. The latest app version is 62, which you can see in the keys form.meta.app_build_version, and metadata.app_build_version. But you can also see version 20 in keys form.@version, form.meta.appVersion, metadata.appVersion, and at the bottom in version.

I could tell from the rest of the form data (not shared here) that there were some obsolete questions from an older version, and yet from this submission, the app seems to be updated for this user. Could it be that the data collector updated the app version but had a pending incomplete form from an older version which was re-opened after the update, completed, and finally sent? Or is it something else?

{
    "form": {
        "@uiVersion": "1",
        "@version": "20",
        "meta": {
            "appVersion": "CommCare Android, version \"2.61.5\"(484347). App v20. CommCare Version 2.61.5. Build 484347, built on: 2026-02-16",
            "app_build_version": 62,
            "commcare_version": "2.61.5",
            "drift": "0",
            "geo_point": null,
            "location": {
                "@xmlns": "http://commcarehq.org/xforms"
            },
            "timeEnd": "2026-03-18T06:12:03.605000Z",
            "timeStart": "2026-03-18T05:27:07.003000Z"
        }
    },
    "id": "7b24929e-825c-4b81-bb8c-a97e1ef76ce1",
    "indexed_on": "2026-03-18T21:52:08.163150Z",
    "initial_processing_complete": true,
    "is_phone_submission": true,
    "metadata": {
        "appVersion": "CommCare Android, version \"2.61.5\"(484347). App v20. CommCare Version 2.61.5. Build 484347, built on: 2026-02-16",
        "app_build_version": 62,
        "commcare_version": "2.61.5",
        "drift": "0",
        "geo_point": null,
        "location": null,
        "timeEnd": "2026-03-18T06:12:03.605000Z",
        "timeStart": "2026-03-18T05:27:07.003000Z"
    },
    "problem": null,
    "received_on": "2026-03-18T21:52:07.511588Z",
    "resource_uri": "",
    "server_modified_on": "2026-03-18T21:52:07.680927Z",
    "type": "data",
    "uiversion": "1",
    "version": "20"
}
1 Like
2

Hi there! Great question – you've done some excellent detective work analyzing that JSON payload! Your hypothesis is actually spot on. :bullseye:

What's Happening Here

The scenario you described is exactly what's occurring:

The data collector updated their app from version 20 to version 62, but they had an incomplete (saved) form that was originally started on version 20. When they reopened that saved form after the update and completed it, the form retained certain metadata from when it was first started.

Understanding the Different Version Fields

Here's what each field represents:

  • form.@version and version: These refer to the form's schema version – essentially which app version the form was originally created under. This stays "locked" to version 20 because that's when the form was initiated.

  • form.meta.app_build_version and metadata.app_build_version: These show the current app build version installed on the device at submission time (version 62).

  • form.meta.appVersion and metadata.appVersion: This is a more detailed string that includes both the CommCare Android version AND the app version. Notice it says "App v20" – again, reflecting the version when the form was started.

Why This Matters

This is actually expected behavior and helps explain why you're seeing obsolete questions in the submission – those questions existed in version 20 of your app. Even though the user was on version 62 when they submitted, the form structure itself was from version 20.

Best Practices

To minimize this in the future:

  • Encourage users to complete and submit forms before updating the app
  • If major form changes are being deployed, consider communicating with field staff about clearing any incomplete forms or noting which ones need to be completed pre-update

This is a common scenario in mobile data collection, and CommCare handles it by preserving the form structure to ensure data integrity. You're tracking the right metadata fields to identify these situations!

Does this clear things up for you?