Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.19%. Comparing base (461923b) to head (1a325ea).
Report is 3 commits behind head on main.

@@           Coverage Diff           @@
##             main    #7267   +/-   ##
=======================================
  Coverage   96.18%   96.19%           
=======================================
  Files         369      369           
  Lines       22187    22187           
=======================================
+ Hits        21341    21342    +1     
  Misses        632      632           
+ Partials      214      213    -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Hey @yurishkuro ; please could you help me with something? We recently bumped from 2.6.0 to 2.9.0 and since doing so have noticed all of our trace id's in elasticsearch are being padded with leading zeros.

The only thing we can see in the change logs related to leading zeros is this (we don't use this option btw).

I can't see any reason from this commit why it would affect the storage of spans too?

For context, we use a 16 digit traceid which is a direct correlation to the rayid we get from cloudflare. Padding it with zeros means we now get:

So ideally it's a behaviour we'd like to disable.

@Stono this is because of the upgrade of ES storage to v2 API where OpenTelemetry data is passed through directly to storage. In v1 storage the data was passing through legacy Jaeger data model where TraceID type would return lower 64-bit only hex string if the upper 64-bits were all zeros. In the OTEL data model all 32bit of trace ID are always used.

✨ New Features in v2.8.0:

• [v2] switch memory backend to storage api v2 implementation (@Manik2708 in #7157)