Follow up on this. Finally figured out what was going on. I'll provide follow up on some of my initial comments to make things clearer. First, both versions acted the same because they both had the same source problem with the code.
RECAP:
"The python process indicates it works, the AGOL items themselves show an updated date, [even] the manual "Update" button in AGOL for the sd items appears to "work", but the data in the hosted layers does not change."
The absence of errors and presence of success indicators at all stages is what made this difficult to troubleshoot.
And the hack attempt of updating the layer by updating the sd item manually didn't "work" because the sd item update is not automatically published to the layer item. You have to publish the update to affect the layer. The Python Api call to publish() on the sd item appears to take whatever data is in the sd item in AGOL and move it over. So, if you update the sd item manually in AGOL and then run the publish() function using code THEN it will move the data from the AGOL sd item to the AGOL layer item.
ANSWER:
After figuring out I could manually update the sd item in AGOL, then run publish() using Python and get the layer to update, I focused in on the update() function. This update() function is supposed to update the sd item in AGOL, and programmatically perform the same function as my manual update using the Update Data button. But, it is "sensitive". Turns out that, as the API docs indicate ( https://developers.arcgis.com/python/latest/api-reference/arcgis.gis.toc.html#arcgis.gis.Item.update ), the 'data' parameter is for an "Optional string, io.StringIO, or io.BytesIO. Either a path or URL to the data or an instance of StringIO or BytesIO objects." The essential portion relevant to my problem is that it must be a path. I had mistakingly provided the sd file name and not the path to the sd file. That was the source mistake.
But, the python process would run "successfully" using this bad data parameter value, and the sd item in AGOL and the layer item both showed date/time updates indicating they had "changed". I assumed the date/time change indicated they had been successfully operated on and should have been updated. Turns out though that the Python api update() function on the sd item was not actually working. Once I provided a path instead of a file name the process worked as you would expect. It seems that this had everything to do with
- a path being required,
- with all (super misleading) indications by the process and ArcGIS Online being that the update worked, and
- that there is zero failure notice by the code etc to let you know that the filename is not sufficient for AGOL.
End suggestion would be that a check with raised exception be put into update() to see that a path is provided and not just a filename, or something to that effect, and also maybe for AGOL to not act as though it is updated. The esri update() code, to me, appears to check for os.path.isfile() which should fail on a str filename that is not a path but I guess it doesn't?? [I didn't do an extensive deep dive into the guts of the esri python functionality so that's not full assessment, nor am I a software developer level guy]
Anyway, the api documentation does state that it must be a path or url so really it comes down to my incorrect usage. That said, sure would be useful if update() failed if it it wasn't actually updating the AGOL sd item.
