Skip to main content

Known issues

This article has troubleshooting tips to help you resolve issues you may encounter using Cognite Functions.

Incorrect folder structure when deploying function as a zip file​

Cognite Functions expects handler.py to be at the root of the zipped folder or at a path relative to the root as pointed to by the function_path attribute. Read more. The following error occurs when handler.py is not found at either of those locations.

Error messages:

When using the API to publish the function, you may see this error message in CDF if the function deployment fails:

No Python module found at location "handler.py" in zip-file.

If you use the Cognite SDK to publish the function, you may see this error message if the function deployment fails:

No file found at location.

Cause:

The most common reason for this error is that the root folder has been zipped, and not the folder contents. This is an example of an incorrect folder structure:

func/
├── handler.py
└── requirements.txt

Running the zip command from outside the func/ folder results in an incorrect folder structure.

# pwd: ~/tmp
> zip -r func.zip func/
  adding: func/ (stored 0%)
  adding: func/handler.py (stored 0%)
  adding: func/requirements.txt (stored 0%)

The requirements.txt must be at the root of the zip-file.

Solution:

cd into the func folder before zipping its contents:

# pwd: ~/tmp/func
❯ zip -r func.zip *
  adding: handler.py (stored 0%)
  adding: requirements.txt (stored 0%)

Calling a Cognite Function from within a Cognite Function​

When using API keys, you can call a Cognite Function from another Cognite Function. However, API keys are being deprecated, and Cognite recommends using OIDC. Note that calling Cognite Functions from within a Cognite Function is not supported when using OIDC tokens.

Failed calls without logs​

A function call returns with the status Failed, and there are no logs to explain why it Failed.

Cause:

Cognite Functions does not support the Python logging module, and importing it can in some cases, hide the stack trace of failed calls.

Solution

Try rerunning the function after replacing logging statements with print statements and removing all imports of the logging module.

Multithreading is not behaving as expected​

Cognite recommendeds to avoid using multithreading from within the function.

Faulty requirements.txt​

A faulty requirements.txt will, in most cases, result in error messages from Pip. You can find them in the error attribute of the object returned by the function create operation. If the function deployment fails, the error will also be available in the CDF user interface. However, there have been cases where the pip installation failed, and we could not find any error messages related to the failure in the pip log.

Solution:

Test the installation locally: pip install -r requirements.txt For Cognite Functions on Azure, the requirements.txt-file must be compatible with:

azure-functions
azure-identity
azure-keyvault-keys
azure-storage-blob
cryptography

Wrongly named requirements.txt​

Your function call fails with the following message in the logs.

Error message:

ModuleNotFoundError: No module named ...

Solution:

Check that the file requirements.txt is correctly named. If the filename is misspelled, the packages listed in the file will not be installed, resulting in a ModuleNotFoundError.

Absolute vs. relative imports​

If the following message is present in the function call logs, it can indicate that a relative import could not be resolved.

Error message:

ImportError: attempted relative import with no known parent package

Cause:

The user is attempting to use relative imports within their handler.py.

Solution:

Preferably use absolute imports instead of relative imports. By doing this, you eliminate any ambiguity in where the package should be imported from. See RealPython: Absolute vs Relative Python Imports.

Scheduled function call fails/times out​

The following error message in the function call logs can indicate a problem with the session used to instantiate CogniteClient:

Error message:

Could not fetch a valid token or a valid API key. Unable to instantiate a CogniteClient. Please verify your credentials.

Solution:

Check CDF to see if the OIDC settings have been updated, as this will revoke all existing sessions, and all schedules will fail. Recreate the function schedules to solve this problem.

Switching from API keys to OIDC tokens​

When using API keys, you can use the function's external_id to link a schedule to the Cognite Function. If you delete the Cognite Function, the linked schedule will persist so that it potentially can be relinked to a new function with the same external_id. However, when using OIDC-tokens, you must link a schedule to a Cognite Function via the function's id. This means that if you delete the Cognite Function, the schedule can never be relinked to any function (because the id never repeats). For this reason, all schedules attached to a function are deleted together with the function.

Connecting to databases outside CDF​

Although connecting to databases outside CDF is technically possible, Cognite will not provide an IP range/CIDR for you to add to an allow list. That would make your database publicly available for any IP, making it highly insecure.

Cognite Functions is intended to be used with data on CDF. Solutions such as Azure Functions or AWS Lambdas may be a better fit for generic or arbitrary code execution.

Download files to the function​

If you are trying to download/create files from within a Cognite Function, you may see this error:

Error message

OSError: [Errno 30] Read-only file system

Solution:

The only directory the function code will have write access to is /tmp. For example, the following snippet creates a temporary directory inside tmp. This directory can be used to create temporary files required during function execution.

with tempfile.TemporaryDirectory() as tmpdirname:
    print('created temporary directory', tmpdirname)
Note!

You cannot rely on files created during the execution of a function to be persisted and available in the next execution.