[Bug]: OTel operation spans report DurableOperationException instead of the original error type #847

Expected Behavior

In both Execution and Invocation trace views, a failed durable operation's exception event should report the original stored error type in exception.type when ErrorObject.errorType is available.

Java should retain its existing exception reporting on Workflow and Invocation spans. The exceptions observed at those boundaries can legitimately be CallbackFailedException or InvokeFailedException. Adding equivalent Workflow/Invocation exception reporting to JS and Python is planned as a separate follow-up.

Actual Behavior

The affected operation spans report software.amazon.lambda.durable.exception.DurableOperationException, even though the original error type is present in the stored ErrorObject. For a failed condition, the attempt span already reports java.lang.RuntimeException, while the enclosing operation reports the wrapper type.

This is a telemetry attribution problem; the requested fix should preserve SDK exception objects and checkpoint contents.

Steps to Reproduce

1. Configure either InvocationOtelPlugin or ExecutionOtelPlugin with an OpenTelemetry SdkTracerProvider and InMemorySpanExporter.

2. Run a handler with LocalDurableTestRunner that throws from a child context:

   var runner = LocalDurableTestRunner.create(
           String.class,
           (input, context) -> context.runInChildContext("otel-failed-child-context", String.class, child -> {
               throw new RuntimeException("Intentional child-context failure");
           }),
           durableConfigWithOtelPlugin);
   runner.run("input");

3. Inspect the exception.type attribute of the exported otel-failed-child-context span's exception event.

4. Observe software.amazon.lambda.durable.exception.DurableOperationException instead of java.lang.RuntimeException.

5. Repeat with a failing waitForCondition, a waitForCallback completed using failCallback with ErrorObject.errorType("RejectedError"), and an invoke completed using failChainedInvoke with ErrorObject.errorType("java.lang.RuntimeException").

SDK Version

Reproduced locally against Java SDK 3.0.1-SNAPSHOT, main commit 64339d4f, with OpenTelemetry 1.67.0.

Java Version

Is this a regression?

Unknown; no last working version has been established.

Additional Context

The code path explains the mismatch:

• BaseDurableOperation.extractErrorFromOperation() represents stored operation errors with DurableOperationException, preserving the original ErrorObject.
• OtelPluginSupport.applyOperationStatus() records the wrapper directly. Its timestamped exception-event path also derives exception.type from the wrapper's Java class.
• The original type remains available through DurableOperationException.getErrorObject().errorType().

The behavior was reproduced locally through the real SDK execution engine and OpenTelemetry provider. Callback and invoke completion were supplied by the local test backend. The reported live AWS/X-Ray traces have not been independently inspected, and no updated deployment has been validated.

Acceptance criteria:

• Operation exception events use the stored original error type when supplied, including remote-language types such as RejectedError, in both trace views.
• Preserve the existing fallback when no stored error type is available.
• Preserve exception-event counts, attempt reporting, message/stack details, event timestamps, and Workflow/Invocation exception reporting.
• Preserve caller-visible failures, serialized checkpoints, and replay behavior; completed user code must remain skipped on replay.

Related closed prototype: #846. This issue retains only the operation-type correction from that prototype; Java's existing Workflow/Invocation exception reporting remains part of the intended behavior. JS/Python parity is a later, separate change.