Requests in internal functions to a non-working ArcGIS Server services causes execution freeze

[sverkerEsriSE]

Describe the bug Accessing some properties or methods on an Item object where the underlying FeatureServer or MapServer is not working will cause an infinite freeze. This boils down to a self._con.post call in the self._refresh method of the Item object. The reason, in our case, for the service not working was a deleted table in the database. Perhaps this can be considered an edge case. Tested with 2.0.0 of the API

To Reproduce Steps to reproduce the behavior:

1. Publish a service which uses an enterprise geodatabase to ArcGIS Server
2. If necessary, add an item in Portal referencing the service published in step 1
3. Delete the underlying feature class from the enterprise geodatabase. This may need to be done in SQL Server Management Studio (or similar) or disable schema locking at the service in AGS Manager, if not able to delete it from ArcGIS Pro/ArcMap.
4. Make sure the service is still running
5. Run the code below

from arcgis.gis import GIS
gis = GIS(portal_url, username, password)
item = gis.content.get("<itemid>")
print(item.shared_with)

error: it just sits there, waiting. To end, kill the python process/kernel.

Expected behavior I expect the Python API to throw an error (perhaps by adding a timeout value to the post request).

Platform (please complete the following information):

• OS: Windows 10
• Python API Version 2.0.0
• Python 3.7.11 from ArcGIS Pro 2.9.2

Additional context I've tracked down the request freezing to the line below (in my case, where the Item was a Feature Service) Line 14549 in the file \Lib\site-packages\arcgis\gis__init__.py

dictdata = self._con.post(
                            self.url, params
                        )

A bit more context, starting at line 14541

        else:
            try:
                if is_raster:
                    dictdata = self._con.post(
                        self.url, params, timeout=None  # token=self._lazy_token,
                    )
                else:
                    try:
                        dictdata = self._con.post(
                            self.url, params
                        )  # , token=self._lazy_token)

[nanaeaubry]

Thank you for reporting this, we will take a look

[achapkowski]

Can you update to version 2.0.0? Version 1.6.2 is very old.

[sverkerEsriSE]

Can you update to version 2.0.0? Version 1.6.2 is very old.

Sorry, I just missed editing the "Issue template". I tested this using 2.0.0 on Python 3.7.11 (ArcGIS Pro 2.9.2), Windows 10

[AndrewBuiltThis]

Has there been any movement on this? This is a pretty problematic situation as we can't build reporting processes because broken content (which we want to identify and report on) causes the reporting process to just stall out completely

[achapkowski]

If the server is holding the connection and not returning the data, then you have to wait for the timeout to happen.

Try setting the timeout to something lower:

GIS(<credentials>, timeout=15)

[AndrewBuiltThis]

@achapkowski Unfortunately that doesn't seem to impact the behavior. I set the timeout to 10 and the process still freezes, locking up the entire process and requiring the python process or kernel to be forcibly killed.

[nanaeaubry]

@AndrewBuiltThis
We are going to tackle this issue but it will be in a future release. Once it has been resolved we will post what version you can expect the fix to be at and if we have suggested workarounds. Sorry for the delay on it

[achapkowski]

honestly, the problem is with the way you erased the table, have you tried re-creating a dummy table in the DB then deleting the service?

[sverkerEsriSE]

honestly, the problem is with the way you erased the table, have you tried re-creating a dummy table in the DB then deleting the service?

Yes, you're right the problem is how the table was erased, but this stuff happens all the time. Should be handled in the Python API so it doesn't completely stall when this is encountered.

Have not tried recreating the table in the db (or dummy table), and right now, I'm not doing any work where I encounter this issue.