跟踪：通过过程调用从父级传播到子级的 span 和跟踪 IDs¶

In event tracing, span and trace IDs behave as follows:

Before the change:

The trace_id of 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_id field does not exist in the RECORD column of the event table.

Native apps providers and consumers see different trace_id values for shared events. The provider sees the hashed version.

After the change:

此更改为使用 JavaScript 和 Snowflake Scripting 编写的处理程序添加了跟踪 ID 传播支持。对于使用 Python、Java 和 Scala 编写的处理程序，此更改已存在。新的行为适用于使用 JavaScript 编写处理程序的存储过程和 UDFs，也适用于使用 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 a parent_span_id attribute.

Spans generated by chained stored procedures or UDFs with JavaScript or Snowflake Scripting handlers have a parent-child relationship between parent_span_id and span_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_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 JavaScript or Snowflake Scripting stored procedure or UDF events, so they can be debugged more easily.

做出这一更改是为了改进调试。

参考：1683