Tracing: Span and trace IDs propagated from parent to child through procedure calls¶
Attention
This behavior change is in the 2024_06 bundle.
For the current status of the bundle, refer to Bundle History.
In event tracing, span and trace IDs behave as follows:
- Before the change:
The
trace_idof each of the spans created by chained stored procedures or UDFs is unique when the handler is written in JavaScript or Snowflake Scripting.The
parent_span_idfield does not exist in the RECORD column of the event table.Native apps providers and consumers see different
trace_idvalues for shared events. The provider sees the hashed version.- After the change:
This change adds trace ID propagation support for handlers written in JavaScript and Snowflake Scripting. This already exists for handlers written in Python, Java, and Scala. The new behavior applies to stored procedures and UDFs whose handlers are written in JavaScript, as well as to stored procedure handlers written in Snowflake Scripting.
Spans generated by chained stored procedures or UDFs with JavaScript or Snowflake Scripting handlers have the same
trace_id. The RECORD column may have aparent_span_idattribute.Spans generated by chained stored procedures or UDFs with JavaScript or Snowflake Scripting handlers have a parent-child relationship between
parent_span_idandspan_id. Stored procedures with JavaScript or Snowflake Scripting handlers can call other stored procedures in a chain of any length. 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 stored procedure or UDF with a JavaScript or Snowflake Scripting handler was called by the user directly (the root), then the
trace_idwill be a random ID and there will be noparent_span_id. If tracing is disabled for a stored procedure and it calls another stored procedure or UDF, then thetrace_idof the child’s spans will be random and they will have noparent_span_id. In other words, the trace is restarted at the child.Native apps providers and consumers see the same
trace_idfor shared JavaScript or Snowflake Scripting stored procedure or UDF events, so they can be debugged more easily.
This change is being made to improve debugging.
Ref: 1683