Register SpanLinkAdapter and SpanLinkJson for reflection

[luneo7]

What Does This Do

Uses a initialization-on-demand holder idiom for the DDSpanLink encoder to make sure that it is not initialized more than once, so it is thread safe. During debugging we saw a bunch of

java.lang.IllegalArgumentException: Expected at least one @ToJson or @FromJson method on datadog.trace.agent.core.DDSpanLink$SpanLinkAdapter
	at com.squareup.moshi.AdapterMethodsFactory.get(AdapterMethodsFactory.java:153)
	at com.squareup.moshi.Moshi$Builder.add(Moshi.java:223)
	at datadog.trace.agent.core.DDSpanLink.getEncoder(DDSpanLink.java:99)
	at datadog.trace.agent.core.DDSpanLink.toTag(DDSpanLink.java:77)
	at datadog.trace.agent.core.DDSpanContext.processTagsAndBaggage(DDSpanContext.java:789)
	at datadog.trace.agent.core.DDSpan.processTagsAndBaggage(DDSpan.java:703)
	at datadog.trace.agent.common.writer.ddagent.TraceMapperV0_4.map(TraceMapperV0_4.java:219)
	at datadog.trace.agent.common.writer.ddagent.TraceMapperV0_4.map(TraceMapperV0_4.java:20)
	at datadog.communication.serialization.msgpack.MsgPackWriter.format(MsgPackWriter.java:84)
	at datadog.trace.agent.common.writer.PayloadDispatcherImpl.addTrace(PayloadDispatcherImpl.java:80)
	at datadog.trace.agent.common.writer.TraceProcessingWorker$TraceSerializingHandler.onEvent(TraceProcessingWorker.java:239)
	at datadog.trace.agent.common.writer.TraceProcessingWorker$TraceSerializingHandler.consumeFromPrimaryQueue(TraceProcessingWorker.java:258)
	at datadog.trace.agent.common.writer.TraceProcessingWorker$DaemonTraceSerializingHandler.runDutyCycle(TraceProcessingWorker.java:155)
	at datadog.trace.agent.common.writer.TraceProcessingWorker$DaemonTraceSerializingHandler.run(TraceProcessingWorker.java:145)
	at [email protected]/java.lang.Thread.runWith(Thread.java:1596)
	at [email protected]/java.lang.Thread.run(Thread.java:1583)
	at org.graalvm.nativeimage.builder/com.oracle.svm.core.thread.PlatformThreads.threadStartRoutine(PlatformThreads.java:838)
	at org.graalvm.nativeimage.builder/com.oracle.svm.core.posix.thread.PosixPlatformThreads.pthreadStartRoutine(PosixPlatformThreads.java:211)

which means that SpanLinkAdapter and SpanLinkJson were not registered for reflection to be used on GraalVM.

Registration for SpanLinkAdapter is required so Moshi is able to build the adapter during runtime, and for SpanLinkJson as well, since this is lazy init GraalVM can't auto infer reflections.

Motivation

SpanLinkAdapter was failing, thus producing invalid payloads (we also raised support request number 1631888)... there you can see the payload and logs for the auto instrumentation and DD side car.

We've have conducted load tests with the change in our environments and with the change theCannot decode v0.4 traces payload: msgp: attempted to decode type "array" with method for "str error message is gone, and we didn't see any error whatsoever.

Fixes

#6889

[luneo7]

Btw tests are failing because:

AWS infastructure is not configured correctly for auto-injection testing
Datadog agent is not configured correctly for auto-injection testing

Seems something wrong with CI?

[luneo7]

@dougqh @ygree is there a way to re-trigger (re-run) the tests? last run failed with

Could not create service of type UserHomeScopedCompileCaches using UserHomeScopeServices.createCompileCaches().
   > Timeout waiting to lock Java compile cache (/home/circleci/.gradle/caches/8.4/javaCompile). It is currently in use by another Gradle instance.

[luneo7]

@ygree @mcculls are you able to do a review of this as well? 🥺

[bm1549]

Merged - thank you for your contribution!

Based on our normal release schedule, this is expected to be released the second week of May

[luneo7]

Thank you! We are using a patched in-house built version of 1.32.0... since that "bug" was flooding our logs with decode error, and we were losing traces.