Remaining work items for Java SDK OpenTelemetry plugin GA readiness

[ayushiahjolia]

This ticket tracks the remaining open work items for the Java SDK OTel plugin before it can move from experimental/preview to GA. The plugin currently produces correct spans for steps, waits, retries, and child contexts using InMemorySpanExporter in tests, but several gaps remain for production readiness and correctness.

1. Replace SamplingUtil with TraceIdRatioBased sampler - Done (refactor(otel): Accept builder, remove custom sampling #436)
2. Add test validating spans in X-Ray / OTLP collector (not just InMemorySpanExporter)
3. Update replay logic to use UpdatedOperationId list from backend - Done (feat(sdk): Add UpdatedOperationIds support for replay status tracking #439)
4. Discuss/Implement how to handle virtual context/operation
5. Discuss/modify onOperationStart replay behavior
6. onOperationStart during lambda suspension?

Stretch goal -

1. Add rawId / SequenceId support
2. W3C traceparent extraction support
3. No arg Otel plugin Constructor

Out of scope, but related -

1. Discuss correct behavior of logging during replay, when to switch execution mode? - [Feature]: Use per-context replay status for logging #383

[SilanHe]

Regarding

5. Discuss/modify onOperationStart replay behavior

I think we can fire the onOperationStart hook when we see the STARTED status on the operation. Did you have something else in mind?

[UPDATE]: we are now including a isReplay field in the OperationInfo. This is false for the first time the onOperationStart is called for the operation and true for subsequent calls

[SilanHe]

4. Discuss/Implement how to handle virtual context/operation

Sometimes a virtual context can span multiple invocations. So I think we should either trigger the hooks every time or never for virtual context.

I'm leaning towards triggering the hooks every time since it's representative of what's happening during the invocation. Virtual context have to be replayed every time. It's possible that the operations within it aren't (since their results are checkpointed), but technically we run the code within a virtual context every time since we don't checkpoint the result.
The benefit of triggering the hook every time (being transparent in this case) would help show that if the durable lambda tends to be invoked many times, it will show that the virtual context is taking up compute time, meaning that the customer should optimize by using a non virtual context.

What do you think?