Python Snowpark Stored Procedures and UDFs: Tracing improvements in Event table¶

Users can now see how queries from chained calls are linked when a Python stored procedure calls another Python stored procedure or a Python stored procedure calls a Python UDF. To use this capability, an Event table must be configured and tracing must be enabled. The values displayed in the TRACE:"trace_id" and RECORD:"parent_span_id" columns of the Event table are as follows:

Before the change:

The trace_id of each of the spans created by chained Python stored procedures or UDFs is unique. The parent_span_id field does not exist in the RECORD column of the Event table. Native apps providers and consumers see different trace_ids for shared events. The provider sees the hashed version.

After the change:

Spans generated by chained Python stored procedures or UDFs have the same trace_id.

Spans generated by chained Python stored procedures or UDFs have a parent-child relationship between span_id and parent_span_id. Python stored procedures can call other stored procedures in a chain of any length, but UDFs can’t execute SQL statements so calling a UDF ends the chain. However, the trace info is still propagated to the UDF’s spans.

If the Python stored procedure or UDF was called by the user directly (the root), then the trace_id will be a random ID and there will be no parent_span_id. If tracing is disabled for a stored procedure and it calls another stored procedure or UDF, then the trace_id of the child’s spans will be random and they will have no parent_span_id. In other words, the trace is restarted at the child.

Native apps providers and consumers see the same trace_id for shared Python stored procedure or UDF events, so they can be debugged more easily.

Native Apps providers who share applications containing Python stored procedures that call other Python stored procedures or UDFs expose the call stack and parent-child relationships of the stored procedures to the consumer. To avoid this, disable tracing.

Ref: 1520