Version Differences Pane Doesn't Have Common Ancestor

[KellySchon]

Has anyone ever seen a situation where when viewing a set of Version Changes in the Differences Pane, a non-inserted feature is missing a common ancestor?

We're using Enterprise 11.3 and Pro 3.5.5 with a published feature service sourced to a branch versioned SQL database.

This is throwing off our approvers because even though this particular editor didn't create this feature in this version, due to the lack of a common ancestor, Pro is highlighting every field as a difference. Which means they can't tell what the editor was attempting to update on the feature and determine whether it should or shouldn't have been deleted in default.

Is this expected behavior from Pro? Is there a valid scenario where a non-inserted feature in a branch version wouldn't have a common ancestor with default?

[JackBravo]

I've seen similar behavior a few times with branch versioning. If a feature doesn't have a valid common ancestor, ArcGIS Pro may treat all attributes as different, even if the editor only changed one field. This can happen after certain reconcile/post operations, version recreation, or if the feature history has become inconsistent. I'd check the feature's edit history, confirm the GlobalID hasn't changed, and make sure all versions were reconciled correctly. If everything looks normal, it may be worth testing in a newer Pro/Enterprise version or opening a case with Esri, as this doesn't seem like expected behavior for a standard update.

[Robert_LeClair]

This is not something I’d consider expected behavior for a non-insert in branch versioning.

In the Differences pane for branch version changes, ArcGIS Pro is intended to show three representations per feature—Current, Target, and Common ancestor. The Common ancestor is defined as “the state of the feature in the current version before it was edited.” If the feature is categorized as Update (not Insert), Pro should generally be able to show that pre-edit state so only the truly changed fields are highlighted.

"Is there a valid scenario where a non-insert has no common ancestor with default?"  At a version lineage level, a “common ancestor” moment exists (it’s the last moment the version and default referenced the same state).

But what you’re describing is more specific: Pro can’t retrieve/represent the feature’s ancestor state in the Differences grid, so it flags everything. That usually points to a limitation/defect or a data/state edge case (rather than a normal editing scenario).

What I need to narrow this down

1. In the Differences list, is the feature under Update, Delete, or Insert?
2. Does this happen for all approvers / machines, or just one?
3. Is the layer coming from the branch versioned feature service only, or can you reproduce it when connecting directly to the enterprise geodatabase branch version (not through the service)?
4. Has Prune Branch History been run recently, or do you use replicas/offline workflows? (These can affect what historical “moments” remain available, and are called out in branch history docs as related to referenced moments and pruning.)

If you answer those, I can check for known issues/KBs specific to Pro 3.5.x + Enterprise 11.3 and the Differences pane/common-ancestor display.

[KellySchon]

1. The feature is listed under Updates.

2. I've only had reports from one approver, and it doesn't seem to be happening consistently across every version they open. When i originally attempted to replicate by looking at the same version, I wasn't able to. I had to spot check a bunch before I found another instance of the behavior. 

3. I've only looked at it coming from the feature service; I didn't actually know that there was a way to access, not just view, branch versions via the DB connection.

4. We have never run Prune Branch History on this database. We do have one offline workflow, but it's not on this specific feature service. It's sourced to the same underlying data, but using a separate service for read/write purposes.

I appreciate your help!

[Robert_LeClair]

Thanks for the info!

A non-insert (listed under Updates) should normally have a Common ancestor representation available in the Differences pane—because Pro defines Common ancestor as “the state of the feature in the current version before it was edited.” If Pro can’t retrieve that representation for a feature that’s categorized as an update, it’s typically pointing to an inconsistency in branch versioning metadata or a service/query issue, not an expected editing scenario.

One known, relevant class of problems is branch versioning metadata becoming inconsistent under conditions (features may end up “referencing a moment before the common ancestor moment” or otherwise not participating correctly in version operations). Esri documents this as a workflow issue and provides guidance for reviewing branch recovery versions after upgrades here - https://support.esri.com/en-us/knowledge-base/000032501 

Also, there are ArcGIS Server fixes/patches around branch queries and the “ancestor moment timestamp” being used correctly for branch requests (again, not exactly your UI symptom, but related to retrieving the correct historical representation)

Now to why it might be for only one approver - perhaps it's because you’re seeing it only via the feature service, and only intermittently, two things to consider:

• whether Pro is intermittently failing to retrieve the ancestor representation from the service (auth/token/session/network/cache), or
• whether only a subset of rows has missing/incorrect branch metadata (so only certain features/versions show it).

To isolate the cause, try these checks the next time you catch/see the issue.

1. Have the approver reproduce, then immediately test the same version/feature on another machine/user.  If only one user sees it, collect their Pro version/build, Windows profile, and whether they’re using the same portal connection.

2. Compare through a different path (service vs direct admin inspection. You can’t view/edit named branch versions via an .sde connection (only Default), but you can use an .sde connection for version administration and inspection.

3. Check whether the feature has odd system field patterns when the issue occurs (GlobalID, editor tracking fields, etc.) and whether the “Update” might actually be a delete/insert pattern coming from your workflow (some edits can be represented that way depending on the operation).

To get your approvers unstuck, here's a potential workaround - when this occurs, have them use the map pop-up / attribute table plus the Version Changes list to identify which fields the editor touched (editor tracking fields can help), since the Differences grid isn’t reliable for that record in that run. Not ideal, but it’s the fastest operational workaround.

Hope this helps!