ExternalFunction names leave out argument types, so Snowflake rejects GRANT OWNERSHIP on them

[GClunies]

Problem

ExternalFunction.fqn has no argument types. The UDF classes (JavascriptUDF, PythonUDF) add them through udf_fqn in snowcap/resources/function.py. Snowflake identifies a function by its name and its argument types, so statements that name an external function need the signature.

Example: a config declares an external function with one VARCHAR argument, and gives it a new owner. Snowcap plans a transfer and sends:

GRANT OWNERSHIP ON FUNCTION MY_DB.MY_SCHEMA.MY_FN TO ROLE NEW_OWNER COPY CURRENT GRANTS

Snowflake rejects it:

090208 (42601): Argument types of function must be specified.

The statement Snowflake expects is:

GRANT OWNERSHIP ON FUNCTION MY_DB.MY_SCHEMA.MY_FN(VARCHAR) TO ROLE NEW_OWNER COPY CURRENT GRANTS

How to reproduce

from snowcap.enums import ResourceType
from snowcap.identifiers import URN
from snowcap.lifecycle import transfer_resource
from snowcap.resources import ExternalFunction

fn = ExternalFunction(
    name="MY_FN", database="MY_DB", schema="MY_SCHEMA",
    args=[{"name": "x", "data_type": "VARCHAR"}], returns="VARIANT",
    api_integration="MY_API", as_="https://example.com/x",
)
print(fn.fqn)  # MY_DB.MY_SCHEMA.MY_FN, with no (VARCHAR)
print(transfer_resource(URN.from_resource(fn, account_locator="ABC123"), "NEW_OWNER", ResourceType.ROLE, copy_current_grants=True))

Scope

Not verified: other statements that name an external function, for example a drop or a privilege grant, can have the same problem. A fix changes how Snowcap identifies an external function, so it can also change how a plan matches it to live state. Two functions with the same name and different signatures are a case to test.

Context

Found during review of #84. That PR fixes the object type only (EXTERNAL FUNCTION becomes FUNCTION), not the name.

[github-actions]

Triage of #85

Type: bug. Suggested labels: bug.

Report quality: Good. It has a standalone Python repro, the expected vs. actual SQL, and the Snowflake error. It's missing the snowcap version, but the static check below doesn't depend on it.

Static check: The report looks plausible against current code.

• ExternalFunction (snowcap/resources/external_function.py:42) defines no fqn property, so it uses the default from snowcap/resources/resource.py (~L766/L807), which has no arg_types.
• JavascriptUDF and PythonUDF set fqn via udf_fqn (snowcap/resources/function.py:158, :326, :330-338). StoredProcedure does the same (snowcap/resources/procedure.py:179-190).
• FQN already renders arg_types as (…) (snowcap/identifiers.py:61-65), so the fix may be an fqn override on ExternalFunction. It would mirror udf_fqn, and udf_fqn could possibly be reused.
• transfer__default (snowcap/lifecycle.py:871-887) emits urn.fqn directly, which matches the unsigned GRANT OWNERSHIP ON FUNCTION … in the issue.

Open questions (as the issue notes):

• Other statements that name the function (drop, grants) likely share the cause, since they all go through the FQN.
• Changing the FQN changes URN identity. Plan matching against live state needs checking, including two overloads with the same name and different signatures.
• Remote fetch may need to produce arg types for external functions too. Compare how fetch_function populates them for UDFs.

Duplicates: None found among open issues (search for "ExternalFunction"). #84 is related (it fixes the object type only).