Remove Orphaned Versions Created by Collector

[JeffreyWalker]

Collector for ArcGIS replica versions are being orphaned after the map is removed from the device.  This puts a lock on the versions and does not allow them to be removed after running a reconcile and post.  Need to add a way to identify orphaned replicas and remove when the 'Delete Versions' box is checked while running a reconcile and post.

[ScottPrindle]

Hello Jeffrey,

Thank you for submitting this idea. Currently, the Replicas list can be used to identify the Replica ID of any orphaned replicas, and the unregisterReplica operation can be used to clean up the versions used during the sync process. If this is still an issue, consider contacting Esri Technical Support to determine what the exact cause of orphaned replicas and which versions of Collector may be affected.

Others,

When voting for this idea, please consider commenting to share your perspective on this topic.

Thanks,

Scott

[HillaryBjorstrom]

i have the same issue. i have a script that is set to list versions, then reconcile and delete. 

But all versions say to have children. i have a hard time telling if the version is still on the device and being used or if it was downloaded and removed without a sync.

[ScottPrindle]

Hello Hillary,

The links from my previous comment should help resolve any issues you're encountering with orphaned or other problematic versions. You will want to manage replicas through the feature service that created them, since there are dependent versions that get created to manage what is sent/received during the sync process. The replicas resource should show information about which replicas remain open (and will ultimately cause issues with your automated scripts), as well as other identifying information. The unregisterReplica operation will unregister whichever replica ID is supplied. Collector uses this operation when data is removed from a device. If Collector is unable to send that request to the server, or it fails for any reason, then the replica will appear to be orphaned, along with all version associated with it.

After all replicas have been unregistered through REST, the scripts you have configured should work as designed. But before we attempt to reconcile and post or delete versions in Desktop or directly in a DB, the replica must be taken care of.

Thanks,

Scott

[HillaryBjorstrom]

This seems like it should work but i don't get any results. Is there any other way to see if the replica is invalid? Would i look in the database for just sends or a specific statement? Thanks

[ScottPrindle]

Hello Hillary,

Are you not getting results when looking at the Replicas resource? If you do not see any replicas, but think that there should still be some for a particular service, you may want to sign into REST to view the replica list as an administrator or the user that originally created the replica. An administrator should be able to see every replica that exists for a service, while the user that created it should see all replicas they own.

Generally, it is best to start investigating these things as far away from the database as possible. This would mean opening Collector to see if the replica can be unregistered using the UI, then moving to the REST Services Directory to attempt the same process manually, and if these options are all exhausted, finally opening up the database to attempt to clean up or remove "orphaned" replicas. The reason this is so important is because something downstream (Collector, ArcGIS Server) may hold onto a reference or object that is tied to the replica that sits in the database.

Always start from the outer-most point and work inwards. And please feel free to PM me if you'd like to go into more detail on your investigation of replicas/versions.

Thanks,

Scott

[ThomasColson]

So here's a vague use case: When I was "testing" the whole offline map archive-enabled feature class thingy in Pro, was creating a LOT of "Download Map". I just checked, and those 30 or so orphan replicas where there. Orphan because I did something purposely to create the orphan. Promptly forgot about them. Would be nice if I could unregister all 30 of them at once, but I suspect there's python magic that does this. 

[AdrienHafner]

Hi Scott,

Thank you for the information on unregistering replicas.  Unfortunately, the links you've provided appear to just be for the REST API.  Like Hillary, I'm running a Python script that lists the versions, reconciles and deletes them (if they are found to not have a replica), which is an Esri example script found here .  The issue is, orphaned replicas (sync_send versions that are the result of a failed Collector sync attempt) are not listed by the Python function arcpy.da.ListReplicas, so when the script runs and adds them to the list of versions to be deleted, the script fails, because it actually DOES have dependent children, they're just not seen by the ListReplicas function.  This is why we either need a) a way for arcpy functions to see all replicas, including sync_send orphaned replicas or b) some other way to delete/unregister them in an automated (python) fashion.

Thanks,

Adrien

[ScottPrindle]

Hello Adrien Roth,

The reason I shared these links is because we should first be approaching these versions and their cleanup from the client that created them, in this case ArcGIS Server. The REST API provides some tools to unregister a replica, which has created and managed all of the SYNC_SEND, etc. versions. Before going to arcpy.da.ListReplicas or directly to the DBMS, these should be investigated at REST first.

Unregistering the replica at REST will normally clean up all of those dependent child versions, but it will also leave the initial child "Esri_Anonymous_service_###########" (in case there are edits that have not been rec/posted back to the parent version). If everything has been done properly through ArcGIS Server and the REST API, but orphaned SYNC_SEND or other versions still exist, then there is likely an issue that Esri technical support should be made aware of. As long as the replica remains in the replicas resource, then those child versions should remain as well.

Additionally, whenever something appears to have gone wrong with sync, consider temporarily bumping your ArcGIS Server logs up to DEBUG level and reproduce the failure or behavior that appears to orphan versions. The service with relevant messaging will usually be the SyncTools GP service. These logs collect a lot of information, so it should only be done when necessary. However, these logs can be extremely useful when you contact Esri technical support about sync issues.

Thanks,

Scott

[AdrienHafner]

Thanks for your reply, Scott.  I actually do have an Esri case open regarding this issue, I just figured I would help investigate if possible.  I wish there was a way to automate the unregister replicas function via Python, as we've had sync issues fairly commonly (at least once a week), and as long as we are, we're not able to automate the rest of the reconcile/delete versions portion of the workflow.  

[MPC_KineticGIS_Department]

Reading through this one is similar to https://community.esri.com/ideas/15983 , the issue is more the interface to deal with all of this needs a lot more work. Personally I avoid the REST API and do everything in python and geoprocessing tools as these are the out of the box toolset provided with package.