This is the root cause of the library where the azure.functions._thirdparty sub-folder failed to reload properly.
The dangling _thirdparty folder is not being treated as a proper Python module.
Thus, when poping out from sys.modules, it is not being recognized as a part of azure.functions. Thus, the topology graph is not built out correctly when removing caches from sys.modules.
try:
module_paths = set(getattr(module, '__path__', None) or [])
if hasattr(module, '__file__') and module.__file__:
module_paths.add(module.__file__)
if any([p for p in module_paths if p.startswith(path)]):
sys.modules.pop(module_name)
except Exception as e:
logger.warning(
f'Attempt to remove module cache for {module_name} but'
f' failed with {e}. Using the original module cache.'
)
Failed with
Attempt to remove module cache for azure.functions._thirdparty but failed with 'azure.functions'. Using the original module cache.
More to investigate
I'm not quite sure why this is triggered when the module is hot-reloaded (a.k.a. Linux Consumption). This should also fail in D
Description
This is the root cause of the library where the azure.functions._thirdparty sub-folder failed to reload properly. The dangling _thirdparty folder is not being treated as a proper Python module. Thus, when poping out from
sys.modules
, it is not being recognized as a part of azure.functions. Thus, the topology graph is not built out correctly when removing caches from sys.modules.Related PR
https://github.com/Azure/azure-functions-python-worker/pull/854
See how azure_functions_worker distribute the _thirdparty package properly
It has __init__.py file defined in it: https://github.com/Azure/azure-functions-python-worker/tree/dev/azure_functions_worker/_thirdparty It is being included in setup.py: https://github.com/Azure/azure-functions-python-worker/blob/dev/setup.py#L389
How this is found
Using this following code for reloading module.
Failed with Attempt to remove module cache for azure.functions._thirdparty but failed with 'azure.functions'. Using the original module cache.
More to investigate
I'm not quite sure why this is triggered when the module is hot-reloaded (a.k.a. Linux Consumption). This should also fail in D