Bug Report: VT_SPAN_CONTEXT ignored in some case

[L3o-pold]

Overview of the Issue

Using a SQL client I manage to use VT_SPAN_CONTEXT for example this query will produce a vtgate log:

/*VT_SPAN_CONTEXT=s==*/select 1;

W0423 07:49:05.656132       7 plugin_mysql_server.go:213] Unable to parse VT_SPAN_CONTEXT: failed to decode span carrier: illegal base64 data at input byte 1

Execute 10.8.8.21:53820 user    'userData1'     'user'  2026-04-23 07:49:05.656227      2026-04-23 07:49:05.656399      0.000173        0.000130        0.000029 0.000000        SELECT  "/*VT_SPAN_CONTEXT=s==*/select :vtg1 /* INT64 */ from dual"     {"vtg1": {"type": "INT64", "value": 1}} 0       0       ""       "PRIMARY"       "7de71520-3ee5-11f1-8dde-dab18bb3b31d"  true    ["commerce.dual"]  "commerce" 0.000000        0.000000        ""      ""

The same query using Laravel framework do not work (no vtgate log saying VT_SPAN_CONTEXT is invalid)

Execute 172.18.0.3:52852        user    'userData1'     'user'  2026-04-23 07:57:44.591212      2026-04-23 07:57:44.591296      0.000084        0.0000660.000011 0.000000        SELECT  "/*VT_SPAN_CONTEXT=s==*/SELECT 1"       {}      0       0       ""      "PRIMARY"       "1c71ad9e-3eea-11f1-8dde-dab18bb3b31d"   false   ["commerce.dual"]  "commerce" 0.000000        0.000000        ""      ""

Reproduction Steps

running vtgate with

    --tracer=opentelemetry \
    --otel-endpoint=jaeger:4317 \
    --otel-insecure=true \
    --tracing-sampling-rate=1.0 \
    --log_queries_to_file=/tmp/query.log

/*VT_SPAN_CONTEXT=s==*/select 1;

DB::connection('vitess')->select('SELECT 1');

Binary Version

vtgate version Version: 24.0.0-rc1 (Git revision 4d416bbc4f652b3839ee393cc0eccf9519c10516 branch 'HEAD') built on Tue Apr 14 13:49:14 UTC 2026 by vitess@buildkitsandbox using go1.26.2 linux/amd64

Operating System and Environment details

docker

Log Fragments

[mattlord]

Hi @L3o-pold!

I'm not sure what to make of this. Do you think this is specific to v24 and the move to open telemetry? I'm guessing that's the real issue here. Right?

It's not clear to me how using the mysql client is different from using Laravel here on the Vitess side of things.

[mattlord]

I can see where this is directly related to the new Otel work: #19619

@timvaillancourt can you please comment on this? I'm not sure why we assume that the value is base64 and if that's a real requirement here or not...

[L3o-pold]

Yeah I do not understand why it do not work as the vtgate query log show similar query in both way.
I used to remember it worked with opentracing in v20 or v21

[arthurschreiber]

Is Laravel using prepared statements?

VT_SPAN_CONTEXT extraction is only wired into ComQuery and ComQueryMulti - ComPrepare and ComStmtExecute, do not call startSpan.

A couple of triage notes:

• The s== value is invalid for the current expected format, so the warning from the SQL client is expected.
• The base64 JSON carrier requirement existed in the old OpenTracing implementation too; OTel still decodes a base64 JSON propagation carrier at go/trace/otel.go:64 and go/trace/otel.go:281.
• I checked v20 and v21; they also only wired startSpan into ComQuery, not prepared-statement execution.

[L3o-pold]

Is Laravel using prepared statements?

yes

The s== value is invalid for the current expected format, so the warning from the SQL client is expected.

yes that's a test case where I expect a warning for invalid value (warning that's not present using Laravel but is using classic SQL client)

I checked v20 and v21; they also only wired startSpan into ComQuery, not prepared-statement execution.

almost sure I managed to make it work using Laravel few years ago but it's old now...

edit: found this screenshot

[arthurschreiber]

almost sure I managed to make it work using Laravel few years ago but it's old now...

Maybe Laravel didn't use prepared statements back then? I haven't looked at older versions, maybe this worked a long time ago and got broken. Either way, to fix this we need to add an equivalent to startSpan handling to ComStmtExecute, and probably ComPrepare too, with tests proving prepared statements with leading VT_SPAN_CONTEXT attempt extraction.

[timvaillancourt]

👋 addressing this in #19958