Carter Kozak

Tracer.startSpan should support overloads to parameterize messages

1

## What happened? We do a great deal of unnecessary string concatenation in span names which can be completely avoided for unsampled traces: https://github.com/palantir/tracing-java/blob/c63567eacecc677c63db0f146fcd2f34493f2ffa/tracing-jersey/src/main/java/com/palantir/tracing/jersey/TraceEnrichingFilter.java#L62 https://github.com/palantir/tracing-java/blob/c63567eacecc677c63db0f146fcd2f34493f2ffa/tracing-okhttp3/src/main/java/com/palantir/tracing/okhttp3/OkhttpTraceInterceptor.java#L42 ## What did you want...

## What happened? TraceEnrichingFilter fails to close spans when AsyncResponse is used.

Support undecided observability state

4

The default sampler should not cause a local service to observe operations, but it should also not prevent upstream tracing-aware services from recording trace data based on their local sampler...

Log consumers should be able to differentiate sampled from unsampled traces

4

## What happened? Log lines inside a traced operation contain a `traceId` [MDC](https://www.slf4j.org/api/org/slf4j/MDC.html) key. Tracing output may be loaded by ID in our logging pipeline, however most traceIds are not...

Completing the wrong span should be impossible

3

Proposal: Opening a span returns a token used to safely close that span, it should not be possible to close the wrong span using this API.

span completion should not return the completed span

1

By returning the completed span we require execution to be traced regardless of whether it will be observed. We can avoid this additional work when tracing is not requested. The...

It should not be possible to create a new trace without also creating a root span. The current API allows for an undefined gap between creating a trace, and opening...

==COMMIT_MSG== Update to latest jdk17 base image ==COMMIT_MSG==

Test latest httpclient release

1

==COMMIT_MSG== Test latest httpclient release ==COMMIT_MSG==

Hybrid (G1) GC uses the defeault 200ms MaxGCPauseMillis on JDK-21+

1

It seems that the heuristics have gone a bit sideways in JDK-21 causing degenerate full gc pauses unnecessarily when we configure `-XX:MaxGCPauseMillis=500`, however setting the default 200ms value resolves this...