Event tracing: Trace IDs propagated from parent to child through procedure calls¶

Before the change:

The trace_id of each of the spans created by chained Java and Scala 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_id values for shared events. The provider sees the hashed version.

After the change:

Spans generated by chained Java and Scala stored procedures or UDFs have the same trace_id. The RECORD column has a parent_span_id attribute.

Spans generated by chained Java and Scala stored procedures or UDFs have a parent-child relationship between parent_span_id and span_id. Java and Scala stored procedures 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 Java or Scala 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 Java or Scala stored procedure or UDF events, so they can be debugged more easily.

Ref: 1592