SNOW-3232869: register_from_file API creating unusable UDF object in database

[BoopalanA]

Please answer these questions before submitting your issue. Thanks!

1. What version of Python are you using?

   Python 3.13.0 (main, Oct 16 2024, 08:05:40) [Clang 18.1.8 ]

2. What operating system and processor architecture are you using?

   macOS-26.3.1-arm64-arm-64bit-Mach-O

3. What are the component versions in the environment (pip freeze)?

   appnope==0.1.4
   asn1crypto==1.5.1
   asttokens==3.0.1
   boto3==1.42.63
   botocore==1.42.63
   certifi==2026.2.25
   cffi==2.0.0
   charset-normalizer==3.4.5
   cloudpickle==3.1.1
   comm==0.2.3
   cryptography==46.0.5
   debugpy==1.8.20
   decorator==5.2.1
   executing==2.2.1
   filelock==3.25.0
   idna==3.11
   ipykernel==7.2.0
   ipython==9.11.0
   ipython_pygments_lexers==1.1.1
   jedi==0.19.2
   jmespath==1.1.0
   jupyter_client==8.8.0
   jupyter_core==5.9.1
   matplotlib-inline==0.2.1
   nest-asyncio==1.6.0
   packaging==26.0
   parso==0.8.6
   pexpect==4.9.0
   platformdirs==4.9.4
   prompt_toolkit==3.0.52
   protobuf==6.33.5
   psutil==7.2.2
   ptyprocess==0.7.0
   pure_eval==0.2.3
   pycparser==3.0
   Pygments==2.19.2
   PyJWT==2.11.0
   pyOpenSSL==25.3.0
   python-dateutil==2.9.0.post0
   pytz==2026.1.post1
   PyYAML==6.0.3
   pyzmq==27.1.0
   requests==2.32.5
   s3transfer==0.16.0
   setuptools==82.0.0
   six==1.17.0
   snowflake-connector-python==4.3.0
   snowflake-snowpark-python==1.47.0
   sortedcontainers==2.4.0
   stack-data==0.6.3
   tomlkit==0.14.0
   tornado==6.5.4
   traitlets==5.14.3
   typing_extensions==4.15.0
   tzlocal==5.3.1
   urllib3==2.6.3
   wcwidth==0.6.0
   wheel==0.46.3
   

4. What did you do?

   I created a Snowpark permanent UDF using session.udf.register_from_file with stage location pointing to a temporary stage. Though the API documentation says temporary stage should not be used, creating UDF with temporary stage is working fine, but the SQL query using the same UDF is failing with import error.

   # Code in 'src/my_snowpark/udf/basic_calc.py' file
   def add_numbers(a: int, b: int) -> int:
       return a+b
   

   Code to create UDF

   from snowflake.snowpark import Session
   from snowflake.snowpark.types import IntegerType
   
   session = Session.builder.app_name('build_udf').config('connection_name','trial').getOrCreate()
   
   session.sql("create or replace temporary stage SNOWFLAKE_LEARNING_DB.public.temp_stage").collect()
   
   session.udf.register_from_file(
       file_path='src/my_snowpark/udf/basic_calc.py',
       func_name='add_numbers',
       return_type=IntegerType(),
       input_types=[IntegerType(), IntegerType()],
       name='add',
       is_permanent=True,
       stage_location='@SNOWFLAKE_LEARNING_DB.PUBLIC.temp_stage',
       replace=True
       )
   
   session.close()
   

   Executed python file

   python3 /src/my_snowpark/udf/register_from_file.py

   Executed SQL query

        select SNOWFLAKE_LEARNING_DB.PUBLIC.ADD(1,2);
   
   
   

5. What did you expect to see?

   I expected to see 3 as the output the sql query but got this error instead.

     SQL compilation error: Found a function matching SNOWFLAKE_LEARNING_DB.PUBLIC.ADD, but IMPORTS or TARGET_PATH could not be resolved.
   

6. Can you set logging to DEBUG and collect the logs?

   No issue in API code

[sfc-gh-sghosh]

Hello @BoopalanA ,

Thanks for raising the issue.
This is expected behavior.

When you register a permanent UDF, Snowflake doesn't actually store the Python code inside the database engine. Instead, it stores a pointer (metadata) to the .py or .zip file located on the stage you specified and a TEMPORARY STAGE exists only for the duration of the Snowflake session that created it. As soon as session.close() is executed, the temporary stage and everything on it (including your basic_calc.py file) is automatically deleted by Snowflake.

So when you call it from another session, such as SELECT SAMPLEDATABASE.TEST.ADD_NUMBERS_4116(1, 2);
Its throwing expected error 'Found a function matching SAMPLEDATABASE.TEST.ADD_NUMBERS_4116, but IMPORTS or TARGET_PATH could not be resolved.'

So, the correct approach is
If you want a Permanent UDF, you must use a Permanent Stage. If you use a temporary stage, the UDF must also be temporary.

UDF Type	Stage Type	Result
Permanent (is_permanent=True)	Permanent	Works consistently across all sessions.
Permanent (is_permanent=True)	Temporary	Fails once the creating session ends (Your current state).
Temporary (is_permanent=False)	Temporary	Works, but only within the same session.

[BoopalanA]

Hi @sfc-gh-sghosh ,

Thank you for the response.

The explanation that you have provided makes sense, but it looks like it is not always true with different register APIs. I found that session.udf.register API is creating a usable/functional udf in database(across sessions) though the stage location used while creating the UDF was a temporary one. register and register_from_file APIs are working differe tly, is this also expected.

[sfc-gh-sghosh]

Hello @BoopalanA ,

Thanks for the udpate, yes you are right.

register() pickles the Python function and, if the serialized code is ≤ few KBs ,it embeds it inline in the CREATE FUNCTION ... AS $$$$ DDL. The UDF becomes self-contained — no dependency on the stage after creation.

register_from_file() always uploads the source file to the stage and generates a CREATE FUNCTION ... IMPORTS = ('<stage_path>/') DDL. The UDF always depends on the stage.

So that's the reason why the register() function is optimized and it's independent of the stage, whereas register_from_file() is always dependent on the stage, so it's a bug, it's how they are implemented.

I hope its clear now, both functions are working expected as per their design and implementations.

[BoopalanA]

Hi @sfc-gh-sghosh,

Thanks for clarifying the difference beween register and register_from_file. It is helpful. I don't see an issue anymore, so I will close this thread.

Thanks for taking time and explaining the nuances.