Version Differences Pane Doesn't Have Common Ancestor

Question

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?

KellySchon · Answer

Thanks so much for the tips and workaround, Robert.

The good/bad news is that we applied the Branch Versioning Data Consistency Patch last year, so that entirely predates the creation of this problem version. Which means I am going digging again it sounds like!

Robert_LeClair · Answer

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.

* 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.

* 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.

* 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!

KellySchon · Answer

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!