Editing Within Feature Service Only Works on Some Features

[ZachBodenner]

Strange issue here. The setup: I have a map of parks that are classified and symbolized by the attribute field "Assigned." The field contains a domain, either "Assigned" or "Not Assigned." There is an internal and public facing version of the map. The Internal version draws on a service published to our federated server (Enterprise 10.8.1). Editing capabilities are enabled on the feature service, but the issue is that only some of the features within the feature class respond as expected to adjusting the "Assigned" field. As far as I can tell, there is nothing especially in common among the features with accept the edit and those that do not. 

Some extra info, this issue has occurred in the past, when all of our services were run off an ArcGIS Server site and consumed in AGOL. (We've since updated to Portal). The same strange editing behavior occurs in both the web map and the webapp (see attached video clips). However, all  the features in this feature class remain editable in an .mxd/.aprx. which tells me the issue is related to how they are being consumed on the web. Our City has many different feature classes and services consumed in a variety of web locations, and as far as I can tell this is the only one exhibiting this behavior.

Any ideas as to why some features in the feature class would not be accepting the edit via dropdown domain?

[DavidPike]

Looks strange, is it part of a subtype at all, where other attribute values are disallowed etc?

if you deleted all the other values, and then tried to change the domain-ed one, would it still not let you?

have you republished the layer after changes to the schema or domain? If not I would.

[ZachBodenner]

Interesting ideas. There are no subtypes present in the feature class. One thing I have tested since I posted this was to rebuilt the feature class with the following workflow:

New Feature Class -> Import Schema from existing Feature Class (the one with the issues) -> Load Data from previous feature class -> Create desktop map with the same symbology -> Publish fresh service.

This wasn't successful. My next test will be to rebuild the feature class without important symbology or loading data, instead manually setting up the attribute fields, and copy/pasting the features from our main parks feature class (which is separate from the feature class in question), and then set their attributes manually.

[DavidPike]

Have you checked the geometry also? Shot in the dark but maybe..

[ZachBodenner]

Mm, can you elaborate on "check?" You mean run a repair geometry or something?

[DavidPike]

Sure, Check Geometry (Data Management)—ArcGIS Pro | Documentation

plus any spatial tools in your database if you're using one.

[ZachBodenner]

Alas, no success with that, nor with my next-step solution after my first response. Which is interesting, because the parks features I used for that second test came from a completely separate feature class that we've never had problems editing.

[DavidPike]

what a head scratcher.

[ZachBodenner · Accepted solution]

Indeed but I think I managed to find a solution.

So in the feature class in the geodatabase, all of the parks were listed as having <Null> for the Volunteers attribute field. For reasons unknown, in the web map, some of these sowed as Null, and some showed as an empty attribute entry. For the most part, the ones with the empty row allowed the park status to be changed, while the ones with Null present caused the flipping-back error. So what I did was to go into the feature class itself, set all of the parks’ Volunteer fields to just be empty as opposed to <Null>, and after testing some of the parks that were giving me fits earlier, the issue seems to resolve. Why these two fields have anything to do with each other if there is no subtype relationship, I haven’t the foggiest. Computers…