Skip to content

[6to7] Restore public DDTraceId class API#5021

Merged
PerfectSlayer merged 1 commit into
masterfrom
bbujon/128b-traceid-api
Apr 4, 2023
Merged

[6to7] Restore public DDTraceId class API#5021
PerfectSlayer merged 1 commit into
masterfrom
bbujon/128b-traceid-api

Conversation

@PerfectSlayer
Copy link
Copy Markdown
Contributor

What Does This Do

Fix broken public API due to changing DDTraceId from class into an interface.

Motivation

Additional Notes

Fixes #4918
Related to #4938

@PerfectSlayer PerfectSlayer added comp: core Tracer core tag: no release notes Changes to exclude from release notes labels Apr 4, 2023
@PerfectSlayer PerfectSlayer requested a review from a team as a code owner April 4, 2023 08:59
@PerfectSlayer PerfectSlayer force-pushed the bbujon/128b-traceid-api branch from 0e05ff1 to 86fb718 Compare April 4, 2023 09:15
@PerfectSlayer PerfectSlayer merged commit ed55440 into master Apr 4, 2023
@PerfectSlayer PerfectSlayer deleted the bbujon/128b-traceid-api branch April 4, 2023 09:35
@github-actions github-actions Bot added this to the 1.12.0 milestone Apr 4, 2023
@PerfectSlayer PerfectSlayer changed the title Restore public DDTraceId class API [6to7] Restore public DDTraceId class API Apr 4, 2023
bm1549 added a commit that referenced this pull request May 30, 2026
DD64bTraceId is a subclass of DDTraceId, so the JVM must initialize
DDTraceId before DD64bTraceId. DDTraceId.<clinit> in turn initialized
DD64bTraceId by building its ZERO/ONE constants via DD64bTraceId.from(),
a circular initialization dependency. When the two classes were first
touched concurrently from opposite ends -- the service-discovery task
(muteTracing() -> blackholeSpan() -> DDTraceId.ZERO) racing the
application's first span (IdGenerationStrategy.generateTraceId() ->
DD64bTraceId.from()) -- each thread held one class-init lock and waited
for the other, hanging trace creation. This surfaced as recurring 30s
LogInjectionSmokeTest timeouts in CI (latent since #9705 added the
scheduled muteTracing task).

Break the cycle at its source while keeping DDTraceId.ZERO/ONE as public
fields (preserving the API restored in #5021): ZERO/ONE are now instances
of a private DDTraceId subtype (a sibling of DD64bTraceId), so
DDTraceId.<clinit> no longer references the subclass.

Replace the fragile "== DDTraceId.ZERO" identity checks with a
value-based DDTraceId.isZero(). Those identity checks relied on every
zero id being the single ZERO instance; isZero() recognizes a zero id of
any concrete type, so the factories need not route 0 to the singleton and
the propagation codecs no longer mishandle a zero parsed via the direct
64-bit factories.

Add a forked regression test that initializes the two classes
concurrently from opposite ends (deadlocks without the fix), plus
isZero() coverage across the DDTraceId subtypes.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp: core Tracer core tag: no release notes Changes to exclude from release notes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants