[User Error] Successful UpdateFeature REST request results in the feature being deleted from the target (2 part unexpected action)
by
Edit: Yours truly is a big dumb dumb, and had a filter on the MapViewer instance I was using, which is also applicable to the Field Maps map that I was testing this on. So, sure enough, every map I checked, had the feature removed. But, all the data was still there, loading it into ArcPro showed that. Heck, it looks like the values I thought were bad, actually don't matter to the converter, it can handle all sorts of numerical data.
Big W for ESRI, Big L for AgLaCo.
Original Post:
Discovered the bug on Monday, I have no idea how long it has been happening before that. Caught it in the wild yesterday, so I think I have some guesses as to how it is happening, but even if I'm doing something wrong (Which I am, I will get more into that), that shouldn't cause the the feature to be deleted, it should just cause the update to fail. I will go into more detail to describe each problem.
Problem one: Update Features is removing features.
Given that there is a DeleteFeatures REST method, it is my understanding that Update Features should not remove features, it should only change them. I updated a feature yesterday, receiving the following updateResults response:
{
"updateResults":[
{
"objectId":34,
"uniqueId":34,
"globalId":"0bdc2adb-0475-40f4-b6b1-61e11f0abacd",
"success":true
}
]
}
This response communicates that the object was successfully changed, and indeed, when I check the layer in ArcGIS Online, I can see that it was changed... by being completely removed. Notice in the following image the absence of OBJECTID 34 (It is sorted by lowest to highest number).
This on its own is a big problem, but there is a second part to this problem, given the data that I presented to the REST endpoint that might have caused this problem.
Problem 2: Faulty data did not result in a failed update.
I know for a fact that some of the data passed in was faulty. Unfortunately, I do not have all of it logged since the application I am building is still new and is missing logging for some parts(And I never expected a failure like this on the ESRI side of things), but I was able to run the last update again and get a request that is at least similar to what it looked like yesterday.
features=[
{
"attributes":{
"OBJECTID":34.0,
"WEEDID_HISTORICAL":"39-KG",
"LEGAL_LAND_DESCRIPTION":"",
"ROLL_NUMBERS":"",
"OWNERSHIP":"Private",
"CASE_STATUS":"Retired",
"PRIORITY":"(1) Low",
"WEED1":"Scentless Chamomile",
"ACREAGE":0.157932089313962,
"WEED_LOCATION":"this is a testin",
"ACTION":"Compliant",
"SYNOPSIS":"we are still testing ",
"LANDOWNERS":"joe joe",
"NOTES":"July 17/13: On July 15/13 I noticed a large patch of SC in the ditch and along the fenceline. It was raining quite hard so I wrote it down and \r\n\r\ncame back on July 16/13 and picked a large bag. Keep an eye on it. AGLACO -AGLACO\r\n\r\nJune 20,2016: There has been no SC for the past couple years, Case closed. AGLACO",
"GlobalID":"0bdc2adb-0475-40f4-b6b1-61e11f0abacd",
"Shape__Area":1727.9140625,
"Shape__Length":204.00752354538685,
"CreationDate":1.712944949133E12,
"Creator":"AgLaCo",
"EditDate":1737653752023,
"Editor":""
},
"geometry":{Geometry ommitted from this sample}
}]
&rollbackOnFailure=true
&f=json
In the above example, there are several faulty data submissions.
- OBJECTID - This field is your standard run of the mill OBJECTID field, and is not a float. Therefore, obviously wrong (But Arc seems to have no problem tracking this value as a float in other situations, this did take a while to notice after-all).
- CreationDate - This field is the standard Edit Tracking Enabled CreationDate field. This value is supposed to be a long, but in the above example, you can see it has converted into a double written down as a power of 10.
- This is obviously wrong, and this alone should result in the update failing, but the "update" was successful regardless.
- There are fields listed that probably shouldn't be there: Shape_Area, Shape_Length, CreationDate, Creator. If there are fields that shouldn't be there, they should either be only read, or throw an error and fail to update the Feature.
While Javascript doesn't usually care (and indeed, the server even found the right Feature before it deleted it) about floating point numbers vs other ones, I can see a problem with the ArcGIS backbone trying to assign a float value to an int column.
To add more detail, it came to my attention that a library my program uses for reading and writing JSON was writing int and long values to doubles. This didn't seem to cause problems a lot of the time, so I didn't notice at first, but sure enough, points were being removed when I updated them with UpdateFeatures on the Feature Server.
--------------------------
Unfortunately that is all of the information I can provide at this moment on this bug, but I have had it happen to me multiple times before now with the same Layer. I am making a tool that converts Sharepoint Document Libraries to Arc Layers and vise versa, and I already completed the part that copies all the information out of Arc and into Sharepoint, which is how I noticed that features are missing on the original dataset. When checking if the update went through (I was looking for no change or change in a single field), the corresponding Arc field was instead completely gone.
1 Solution
Accepted Solutions
by
