[#1289] feat(sdk): add OpenTelemetry traceparent header propagation in BridgeWatch SDK queries Repo Avatar

[ToryMic]

Summary

Adds W3C Trace Context propagation to the SDK's HTTP queries. Previously, requests made through the SDK carried no traceparent, so an integrating application could not correlate an SDK call with the backend's database spans.

sdk/src/tracecontext.ts

A self-contained implementation of the traceparent / tracestate formats:

• parseTraceparent / formatTraceparent — rejects all-zero trace/span ids, malformed lengths, non-hex characters, and (per the spec) uppercase hex.
• resolveTraceContext — with an inbound traceparent, it keeps the trace id and mints a fresh span id per request. That new span is what appears in the backend's trace and links back to the caller. Without one it starts a new root trace.
• injectTraceHeaders — applies headers without clobbering a traceparent the caller already set, and never forwards tracestate alone (it is meaningless without its traceparent).

Wiring

BridgeWatchSdkConfig.tracing accepts the inbound traceparent/tracestate plus optional startNewTrace and sampled overrides, and fetchCompatibility injects the headers into its request. The existing X-API-Version / Accept headers are preserved. The config field is deliberately excluded from Required<> — propagation is opt-in, and a forced default would misrepresent the no-tracing case.

No backend change is needed for this to take effect end-to-end; the header is additive and ignored by anything that doesn't read it.

Testing

• 37 new tests: 29 unit (tracecontext.test.ts) + 8 integration (tracePropagation.test.ts)
• Integration tests assert the header reaches the outgoing request, that two requests in the same trace share a trace id but get distinct span ids, and that a malformed inbound traceparent is replaced rather than propagated.
• All 37 pass.

Pre-existing failures (not touched here): sdk on main already has 2 type errors in src/contract.ts (result.status === "SUCCESS" where the status union has no SUCCESS, and val.bool() which does not exist on ScVal) and 4 failing tests in client.test.ts / contract.test.ts. Those counts are identical before and after this branch, so this adds no new failures. They look like genuine bugs — status === "SUCCESS" can never be true on a sendTransaction response, and val.bool() would throw at runtime — and I'm happy to fix them in a separate PR so they don't muddy this diff.

Reviewer notes

• The issue title ends with "Repo Avatar", which looks like an artefact of how the issue was generated; I've preserved it verbatim in the branch name and PR title as required, but it's not reflected in the change.
• Span/trace ids use crypto.getRandomValues when available with a Math.random fallback so the SDK still works on runtimes without Web Crypto.

Closes #1289

[drips-wave]

@ToryMic Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits