Incorrect Editor Tracking for feature services in same shared instance

[GarethBaker1]

We have ArcGIS Enterprise 10.9.1 and SQL Server 2017 enterprise geodatabase. There are several feature services published to the hosting server multi-machine site which are used by different sets of editors around the business. These aren't high traffic services so in order to save on server resources the services were set to use the shared instance pool (available if the service is published from Pro).

Editing is being carried out using either the Smart Editor widget in WAB app or via the Field Maps app.  Access to maps and layers is being controlled by Portal groups and none of the content items are shared more widely than groups.

A user of one of the editable layers has noticed odd values appearing in the last edited column of the tracking data - in some cases their name is recorded against features that they know they have not edited and in a small number of cases the name of someone from outside their team has been recorded, despite that person not having access to the layer or map via Portal sharing. From what we can tell it appears that the attribute and/or geometry edits against that particular record are correct, just that the wrong name has gone into the last edited user field.

In one of the cases we can see that the user from outside the team was submitting a record in their own project in Field Maps at the same time (at least to the minute), but that's not always the case.

The only thing we can think of that is linking these users together is that they are all editing feature services that are running as shared instances on the same ArcGIS Server site. So we were wondering if there is some sort of cacheing or mix up of user names going on within the shared instance.

We've now set the feature service that was getting the incorrect tracking to be a dedicated instance and after 24 hours there don't appear to be any rogue editor names from outside the team. It may just be that the exact circumstances which caused the problem have not arisen again and there is no guarantee that the names it has recorded are necessarily correct (unless we specifically ask users to check after each edit).

Has anyone else ever experienced this issue when working with shared instances? There is nothing that I can see in the documentation which says they can't or shouldn't be used for feature access/editing but I think for the time being we will stick to dedicated instances for any editable services.

[ZacharyHart]

@GarethBaker1  Did you ever get to the bottom of this? We have a Federated Enterprise site, single machine/site though, but we are now noticing odd behavior with feature service based editing and editor tracking...erroneous user names. We've been using editor tracking for years and have not noticed this.

We are recently upgraded from 10.7 to 10.9.1 FWIW.

[NeilMYoung]

We are also seeing a similar odd behavior with the wrong editor's name being associated with edits. We are using Enterprise 10.9.0, Federated, and pooled instance services. We recently have been noticing it and tracking it and we have been able to trace back and determine that it started occurring some time late last summer.  It is not predictable, and appears to be fairly random. @GarethBaker1  I am echoing @ZacharyHart 's request to know if you ever did determine a resolution that you can share for the benefit of others that does not include using dedicated instances? We of course would like the benefit of being able to use shared instances if at all possible. This would affect a fair number of services on our project, so could significantly reduce the capacity on our server if all of the shared services we are using currently would need to be dedicated.

[GarethBaker1]

@ZacharyHart @NeilMYoung 

Hi both,

No unfortunately we didn't get to the bottom of this and decided it was too much effort to try and investigate further e.g. getting each user to manually check that the tracking fields are correct after each edit.

We ended up adding a couple of additional fields to the dataset to allow the editors to manually select their name and last edit date. This is somewhat preferential to the automated tracking fields anyway in our case because if I have to do a bulk operation on the dataset then it effectively wipes all the real editors' tracking info and replaces with mine.

[ScotWallace]

I am also seeing similar behavior with this version of Enterprise using VertiGIS Studio Workflow. Updating features via the Update Features workflow activity seems to incorrectly update the editor tracking attributes (last edited by). I've confirmed successful updating via the REST API so this does seem to be an external application issue as we are not using shared instances. Has anyone been able to get to the bottom of this?

[ZacharyHart]

@ScotWallace @GarethBaker1 @NeilMYoung 

We are using dedicated instances in a single machine sight but are seeing a very similar behavior to what @ScotWallace is seeing where the REST API updates as expected but the 3rd party application (created with Esri's SDK) is not updating the editor tracking successfully. 

[ScotWallace]

I've opened a case with ESRI #03165620

[ZacharyHart]

Thanks @ScotWallace ! Please keep us posted.

[ZacharyHart]

@GarethBaker1 @NeilMYoung  @ScotWallace Are you using versioned or nonversioned data in these services?

[ScotWallace]

Non-versioned but the data is archived which ESRI seems to think may be the issue. I received a response from them referencing a known bug: BUG-000146447: When multiple users are editing the same feature layer with different feature points, the enable editor tracking with archiving does not honor 'last_edited_user' in the record. This apparently has been fixed for Enterprise 11.0 but my issue at least is slightly different in that the issue arises when editing new features as well.