Fail to synchronize replica during collaboration

[MatthiasBoucher]

Hello,

I have one ArcGIS enterprise portal synchronizing items every night to ArcGIS Online through a one way Collaboration. Most of my Feature Services are synchronizing successfully but one item is failing every time. The following messages appear in the portal logs during the synchronization attempt :

In the portal sharing logs I have the following messages :

I've been able to create a local replica containing the same data using arcpy, so I don't think there is some corrupted data preventing the replica to work. The size of the replica is also quite small, so I don't think disk size is an issue. I can't find a clue about the severe message "Direction is 'download'", hence this ticket.

Thank you for your help.

Versions : ArcGIS enterprise 10.91. The Feature Service I am trying to synchronize is not hosted. It refers to a PostgreSQL geodatabase. Data are not versionned, but has archiving enabled, contains globalids, and I ran the arcpy "Enable replica tracking" tool on them.

[TimoT]

Hi,

It would be a good idea to closely double check that you have met all requirements as per Esri documentation:

• https://pro.arcgis.com/en/pro-app/latest/help/data/geodatabases/overview/prepare-data-for-collaborat...

One thing you may have missed is that there are certain fields you must not hide. 

Timo

[MatthiasBoucher]

Hello Timo

Thank you for your answer. Judging by the link you provided me, I am in the 1st scenario (archived but non versionned data, one-way synchronization). I tried to re-publish the FeatureServer because I wasn't aware of this publication option : 

but unfortunately this had no effect, I still have the same error message in the portal logs :

The FeatureServer uses data from a geodatabase, so I don't know why the log message refers to a 'hosted feature layer'.

I also checked the fields of the 5 feature layers I'm trying to publish, none of them have hidden fields (only one has a highlighted field).

I copy/paste the data from the original database to a recent PostgreSQL database, then published it and synchronized it through collaboration : it worked. So maybe the problem indeed comes from the original datasource itself ?