The connections provided by the go MySQL driver will return ErrSkip to any SQL query with parameters unless the interpolateParams option is explicitly set to true--it is false by default. (See https://github.com/go-sql-driver/mysql/blob/master/connection.go#L368)
This SDK's implementation of SqlContext creates a subsegment for both the original aborted non-call (which returns ErrSkip and is never executed) and the following actual call to the database.
This causes the majority of SQL queries to show up twice in the trace; one with skip fast-path; continue as if unimplemented appended to the query, and then another with just the query text.
Ideally SqlContext would avoid creating a subsegment when it receives ErrSkip
See https://github.com/aws/aws-xray-sdk-go/blob/master/xray/sql_context.go#L238 if my explanation is confusing
The connections provided by the go MySQL driver will return
ErrSkipto any SQL query with parameters unless theinterpolateParamsoption is explicitly set to true--it is false by default. (See https://github.com/go-sql-driver/mysql/blob/master/connection.go#L368)This SDK's implementation of
SqlContextcreates a subsegment for both the original aborted non-call (which returnsErrSkipand is never executed) and the following actual call to the database.This causes the majority of SQL queries to show up twice in the trace; one with
skip fast-path; continue as if unimplementedappended to the query, and then another with just the query text.Ideally
SqlContextwould avoid creating a subsegment when it receivesErrSkipSee https://github.com/aws/aws-xray-sdk-go/blob/master/xray/sql_context.go#L238 if my explanation is confusing